Udi Dahan wrote an interesting post about how to create fully encapsulated domain models. The post, example code, and comments are all really interesting.

One discussions that arose in the comments was regarding large collections. More specifically, how can business logic access potentially large collections from within entities? It seems that there are a few ideals when it comes to structuring a domain model.

• Queries should be encapsulated inside repositories or query objects
• Business logic should live inside Entities.
• Entities should not depend on Services or Repositories.

These ideals are difficult to achieve. People find themselves using the following patterns.

• Entity depends on Repository.
• Entity depends on Service.
• Put all domain logic in Services and have anemic Entities.

As one commenter noted, it appears that there is no perfect solution here.

They pointed out that having entities depend on repositories and services feels "wrong", even when this is hooked up with DI.

Despite this, I think that that's my favorite option right now. Until someone suggests a better way, my entities will depend on repositories and services where the business logic needs it, and I'll use DI to wire things up.

The reason I like this is that it's consistent. I don't mind breaking consistency for edge cases. But, operations that work on large collections of data are not edge cases. I'd guess that perhaps 40% of business rules require SET based operations that need a repository. So, I want a consistent approach for that 40%. I don't want to have to think "where will the business logic be for this operation?". My logic is in the entities, and the entities will have to use repositories to get at their data.