Question

After a week of learning about Domain Driven Design 10+ hours a day I started feeling like I was beginning to understand it pretty well until I read this article today:

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

The author of that article is saying you inject the Repository into the Domain object and that did not make any sense to me.

I’m no expert on this subject but I think he is wrong but I would like some input from some people here on whether it is right or wrong to inject a Repository into a Domain Object.

With all my reading in the last week everyday as I read another article and another they were all sounding the same to me (which is a good thing) until I saw the article I posted above, it make me think twice if my picture of this pattern is incorrect.

Are you or are you not supposed to inject a Repository?

Answer 1

The example shown is using the Active Record pattern. In this pattern, an entity knows how to save itself. This is generally not considered good Separation of Concerns because the class knows about two things: the data properties and how to persist itself.

Injecting a repository into the Active Record object is better than some Active Record implementations I’ve seen (because you can at least swap out the repository implementation), but in my view (and most of the DDD community) the dependency is backwards:

The repository should depend on the object it returns, not the other
way around. The reason for this is that your “domain object” (more on
that later) can exist (and should be testable) without being loaded or
saved (that is, having a dependency on a repository).

So to answer your question, no. You’re not supposed to inject a repository into a domain object.

However, it’s worth noting that this isn’t really a domain object because it does not have behavior – just simple get/sets (accessors/mutators). It’s just a Data Transfer Object (DTO). If there’s really no behavior, you do not need a domain model – it’s just simple CRUD.