Is Repository Pattern with Domain Driven Design become Anti-Pattern? [closed]

Question

First of all I want to clarify that I am new to Domain Driven Design and I am asking this question because I have read something called Anemic Domain Model.

Most of the time I see following thing while working with Repository pattern.

1. We have One Generic Repository
2. We have Model that only contain set of public properties but it does not contain any method ( So It become Anemic Domain Model as per definition of DDD) because here repository class handle other process for that entity or model.

Please provide your valuable answer for my query.

Let me clarify few things.

Generic Repository means Generic interface that get implemented by Entity repository.

My confusion is regarding following thing

For example: Suppose I want to save

    public class User
    {
        public int Id { get; set;}
        public string Name { get; set};
    }

    public class UserRepository : IRepository<User>  
    {  
        // All Operation Like Save / Get /  UserEntity (Domain Object)       
    }

So here is my User class do nothing instead it just have properties and other operation handle by UserRespository. So my User is Anemic Domain model. ( As it do nothing specific)

Here in attached image I consider ProductRepository so my question is: Is My Product class an Anemic model?

Please consider following Sample Image for what I am trying to say.

Answer 1

I agree that the IRepository interface is generally a waste of time. If I put the basic CRUD operations in my IRepository interface, then how do I deal with data like audit data? Where deleting it would be forbidden. Should I just return a InvalidOperationException when I try to call Delete()?

Some people have suggested smaller interfaces like IReadable, IWriteable, IUpdateable or IDeleteable. I think this approach is even messier.

Personally (and this is just my own solution after giving everything else a good run around the block), for DDD, I prefer to use an interface per repository (mostly for IoC and unit testing). This gives me IUserRepository, IAuditLogRepository, etc. My repositories also take (as parameters) and return domain entities (aggregate roots or just single entities). This way there is no anaemic DTO objects to maintain or clutter my solution. However I still use view-models to keep sensitive data out of my views.

There's lots of arguments online for and against the repository pattern.

Answer 2

The repository pattern is not an anti-pattern per se, but I have seen far to many implementations of DDD where the repository pattern provided little or no value. Hand your n-tier-provide-no-value layered architecture to a pragmatic hardcore expert dev and he will probably give you the "anti-pattern" critique (and valid I might say).

Repository pattern pros:

1. An abstraction of the underlying persistence technology
2. A possibility to define your aggregate roots, only aggregate roots should have repositories
3. A way of explicitly stating which operations are valid for the aggregate root in question, for example if its not valid to delete your entity, your repository should have no delete method.
4. Something that is easy to test without a database (stubbing your repositories)

Repository pattern cons:

1. Closeness to your persistence technology.
2. Yet-another tier

Personally I prefer using the repository pattern when doing DDD, but your solution sounds more like the active record pattern, thus removing most of the benefits of using repositories in the first place. I never do generic repositories because they remove pros 2 & 3 (I can have a generic implementation, but I don't expose it directly to repository-consumer code).

And also: don't use repositories for population of DTOs, ViewModels, etc. Use separate models and technology for modelling writes (DDD can work great) and reads.