3

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?

ibanore
  • 1,500
  • 1
  • 12
  • 25
  • 1
    possible duplicate of [DDD - the rule that Entities can't access Repositories directly](http://stackoverflow.com/questions/5694241/ddd-the-rule-that-entities-cant-access-repositories-directly) – meze Jan 05 '13 at 20:33
  • 2
    In summary: not only is it a bad practice, his examples are awful (UserRepository must return instance of a User object unless you ask a repository to do some calculations/counting). – meze Jan 05 '13 at 20:36
  • Thanks for the reply. Yeah I don't think he should be writing articles about DDD at all. At least now I know that I actually have learned something about DDD in the last week if I can realize when someone is doing it wrong. Still not 100% comfortable with it though I am sure I will be back with more questions soon. – ibanore Jan 05 '13 at 20:46
  • Similar discussion http://stackoverflow.com/questions/14020196/domain-driven-design-and-ioc-dependency-injection/ – zafarkhaja Jan 16 '13 at 21:08

1 Answers1

6

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.

Josh Kodroff
  • 27,301
  • 27
  • 95
  • 148
  • so suppose, I am using elastic search for implementing some search behaviours, then all the search behaviour comes from ES and there is no real business logic I would need. So should I just use a DTO. (I am using separate object for search, which only includes fields required for search). – Code Name Jack Jun 27 '20 at 22:10
  • Yes, basically. Here's how I would model this today in classes: - SearchRequest (plain old DTO) - SearchRequestHandler (with one method: Handle(), takes a dependency on ES) - SearchResponse (plain old DTO) – Josh Kodroff Jun 29 '20 at 20:20