I'm diving in to Domain Driven Design and some of the concepts i'm coming across make a lot of sense on the surface, but when I think about them more I have to wonder if that's really a good idea.
The concept of Aggregates, for instance makes sense. You create small domains of ownership so that you don't have to deal with the entire domain model.
However, when I think about this in the context of a web app, we're frequently hitting the database to pull back small subsets of data. For instance, a page may only list the number of orders, with links to click on to open the order and see its order id's.
If i'm understanding Aggregates right, I would typically use the repository pattern to return an OrderAggregate that would contain the members GetAll, GetByID, Delete, and Save. Ok, that sounds good. But…
If I call GetAll to list all my order's, it would seem to me that this pattern would require the entire list of aggregate information to be returned, complete orders, order lines, etc… When I only need a small subset of that information (just header information).
Am I missing something? Or is there some level of optimization you would use here? I can't imagine that anyone would advocate returning entire aggregates of information when you don't need it.
Certainly, one could create methods on your repository like GetOrderHeaders, but that seems to defeat the purpose of using a pattern like repository in the first place.
Can anyone clarify this for me?
EDIT:
After a lot more research, I think the disconnect here is that a pure Repository pattern is different from what most people think of a Repository as being.
Fowler defines a repository as a data store that uses collection semantics, and is generally kept in-memory. This means creating an entire object graph.
Evans alters the Repository to include Aggregate Roots, and thus the repository is amputated to only support the objects in an Aggregate.
Most people seem to think of repositories as glorified Data Access Objects, where you just create methods to get whatever data you want. That doesn't seem to be the intent as described in Fowler's Patterns of Enterprise Application Architecture.
Still others think of a repository as a simple abstraction used primarily to make testing and mocking easier, or to decouple persistence from the rest of the system.
I guess the answer is that this is a much more complex concept than I first thought it was.
Best Answer
Don't use your Domain Model and aggregates for querying.
In fact, what you are asking is a common enough question that a set of principles and patterns has been established to avoid just that. It is called CQRS.