Are DDD Aggregates really a good idea in a Web Application?

Question

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.

Answer 1

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.

Answer 2

I struggled, and am still struggling, with how to best use the repository pattern in a Domain Driven Design. After using it now for the first time, I came up with the following practices:

1. A repository should be simple; it is only responsible for storing domain objects and retrieving them. All other logic should be in other objects, like factories and domain services.

2. A repository behaves like a collection as if it's an in memory collection of aggregate roots.

3. A repository is not a generic DAO, each repository has its unique and narrow interface. A repository often has specific finder methods that allow you to search the collection in terms of the domain (for example: give me all open orders for user X). The repository itself can be implemented with the help of a generic DAO.

4. Ideally the finder methods will return only aggregate roots. If that's to inefficient it can also return read only value objects than contain exactly what you need (although it’s a plus if these value objects can also be expressed in terms of the domain). As a last resort the repository can also be used to return subsets or collections of subsets of an aggregate root.

5. Choices like these depend on the technologies used, as you need to find a way to most efficiently express your domain model with the technologies used.

Answer 3

I don't think your GetOrderHeaders method defeats the purpose of the repository at all.

DDD is concerned (among other things) with ensuring that you get what you need by way of the aggregate root (you wouldn't have a OrderDetailsRepository, for instance), but it doesn't limit you in the way you are mentioning.

If an OrderHeader is a Domain concept, then you should have it defined as such and have the appropriate repository methods for retrieving them. Just make sure that you're going through the correct aggregate root when you do.

Answer 4

My use of DDD may not be considered "pure" DDD but I have adapted the following real world strategies using DDD against a DB data store.

• A aggregate root has an associated repository
• The associated repository is only used by that aggregate root (it is not publicly available)
• A repository can contain query calls (e.g. GetAllActiveOrders, GetOrderItemsForOrder)
• A service exposes a public subset of the repository and other non-crud operations (e.g. Transfer Money from one bank account to another, LoadById, Search / Find, CreateEntity, etc.).
• I use the Root -> Service -> Repository stack. A DDD service is only suppose to be used for anything an Entity can't answer itself (e.g. LoadById, TransferMoneyFromAccountToAccount), but in the real world I tend to also stick in other CRUD related services (Save, Delete, Query) even though the root should be able to "answer/perform" these themselves. Note that there is nothing wrong with giving an entity access to another aggregate root service! However, remember you would not include in a service (GetOrderItemsForOrder) but would include that in the repository so that the Aggregate Root can make use of it. Note that a service shouldn't expose any open queries like the repository can.
• I usually define a Repository abstractly in the domain model (via interface) and provide a separate concrete implementation. I fully define a service in the domain model injecting in a concrete repository for its use.

** You do not have to bring back an entire aggregate. However, if you want more you have to ask the root, not some other service or repository. This is lazy loading and can either be done manually with poor man lazy loading (injecting the appropriate repository/service into the root) or using and ORM that supports this.

In your example, I would probably provide a repository call that brought just the order headers if I wanted to load the details on a separate call. Note that by having an "OrderHeader" we are actually introducing an additional concept into the domain.

Answer 5

Your domain model contains your business logic in its purest form. All the relationships and operations that support business operations. What you're missing from your conceptual map is the idea of the Application Service Layer the service layer wraps around the domain model and provides a simplified view of the business domain (a projection if you will) that allows the Domain model to change as needed without directly impacting the applications using the service layer.

Going further. The idea of the aggregate is that there is one object, the aggregate root, responsible for maintaining consistency of the aggregate. In your example, the order would be responsible for manipulating its order lines.

For your example, the service layer would expose an operation like GetOrdersForCustomer that would only return what's needed to view a summary listing of the orders (as you call them OrderHeaders).

Finally, the Repository pattern isn't JUST a collection, but also allows for declarative queries. In C# you can use LINQ as the Query Object, or most other O/RMs provide a Query Object specification as well.

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. (from Fowler's Repository page)

Seeing that you can create queries against the repository, it also makes sense to provide convenience methods that handle common queries. I.e. if you just want the headers of your order, you can create a query that returns just the header and expose it from a convenience method in your repositories.

Hope this helps clarify things.

Answer 6

I know this is an old question but I appear to have come to a different answer.

When I make a Repository it's generally wrapping some cached queries.

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.

Keep those repositories in your servers ram. They're not just pass through objects to the database!

If I'm in a web application with a page listing orders, that you can click on to see details, chances are I'm going to want my order listing page to have details about the orders (ID, Name, Amount, Date) to help a user decide which one they want to look at.

At this point you have two options.

1. You can query the database and pull back exactly what you need to make the listing, then query again to pull the individual details you'd need to see on the detail page.

2. You can make 1 query that pulls back all the information and caches it. On the next page request you read from the servers ram instead of the database. If he user hits back or selects the next page you're still making zero trips to the database.

In reality how you implement it is just that, and implementation detail. If my biggest user has 10 orders I probably want to go with option 2. If I'm talking 10,000 orders then option 1 is needed. In both of the above cases and in many other cases I want the repository to hide that implementation detail.

Going forward if I get a ticket to tell the user how much they have spent on orders (aggregated data) in the last month on the order listing page, would I rather write the logic to calculate that in SQL and make yet another round trip to the DB or would you rather calculate it using the data that's already in the servers ram?

In my experience domain aggregates offer huge benefits.

• They are a huge part code reuse that actually works.
• They simplify code by keeping your business logic right in the core layer instead of having to drill through an infrastructure layer to get the sql server to do it.
• They can also dramatically speed up your response times by reducing the number of queries you need to make since you can easily cache them.
• The SQL that I'm writing is often way more maintainable since I'm often just asking for everything and calculating server side.