Is Repository Pattern with Domain Driven Design become Anti-Pattern?

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.

We have One Generic Repository
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.

Could you elaborate more? What makes you thinking that Repository would be an antipattern? Someone's opinion? Your own? Put some value into the question if you expect valuable answers :) — Wiktor Zychla, Aug 07 '13 at 05:56
It is not my own that Repository is anti pattern but I am confuse the way Anemic Domain Model definition and repository pattern. Like Repository pattern take care of save of entity but entity itself does not have any method for save. — dotnetstep, Aug 07 '13 at 06:08
That would be perfectly valid in DDD, think of repositories as services. — Wiktor Zychla, Aug 07 '13 at 06:17
Here is a topic on this question on the DDD\CQRS mailing list: https://groups.google.com/d/msg/dddcqrs/krOf_dqnD8o/qpTc0OPQSMQJ — JefClaes, Aug 07 '13 at 06:34
What do you mean by "We have One Generic Repository". Every aggregate should have specific repository, not generic one. — gseric, Aug 07 '13 at 06:52
Even with your clarification, this is a matter of opinion. No matter what you've read, there is no "correct" answer. — madth3, Aug 07 '13 at 16:03
I have read that if your Model class does not contain behavior it is anemic model. That point trigger to me this question. — dotnetstep, Aug 08 '13 at 09:56
Having a command like `IncreasePrice` on a repository is definitely wrong and generic repositories are usually an anti-pattern. — plalx, Nov 25 '14 at 14:11

score 24 · Answer 1 · answered Aug 07 '13 at 07:00

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:

An abstraction of the underlying persistence technology
A possibility to define your aggregate roots, only aggregate roots should have repositories
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.
Something that is easy to test without a database (stubbing your repositories)

Repository pattern cons:

Closeness to your persistence technology.
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.

score 24 · Accepted Answer · answered Aug 07 '13 at 08:29

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.

Is Repository Pattern with Domain Driven Design become Anti-Pattern?

2 Answers2