DDD - How to implement high-performing repositories for searching

I have a question regarding DDD and the repository pattern.

Say I have a Customer repository for the Customer aggregate root. The Get & Find methods return the fully populated aggregate, which includes objects like Address, etc. All good. But when the user is searching for a customer in the UI, I just require a 'summary' of the aggregate - just a flat object with summarised information.

One way I could deal with this is to call the find method on the repository as normal, and then in the application layer, map each customer aggregate to a CustomerSearchResult / CustomerInfo DTO, and send them back to the client.

But my problem with this is performance; each Customer aggregate may require multiple queries to populate all of the associations. So if my search criteria matched 50 customers, that's quite a hit on the DB for potentially retrieving data I'm not even going to need.

The other issue is that I may wish to include summarised data about the customer that is outside of the Customer's aggregate root boundary, such as the date of the last order made for example. Order has it's own aggregate and therefore to get the customer's order information I would have to call the OrderRepository, also degrading performance.

So now I think I'm left with two options:

1. Add an additional Find method to the CustomerRepository which returns a list of these summary objects by doing one efficient query.

开发者_如何转开发

2. Create a purpose built readonly CustomerInfoRepository, that just has the find method described in 1.

But both of these feel like I'm going against the principles of DDD. My repositories inherit from a generic base: Repository where T : IAggregateRoot. These summary info object are not an aggregates, and are of a different type to T, so really #1 goes against the design.

Perhaps for #2 I would create an abstract SearchRepository without the IAggregateRoot constraint?

There are many similar scenarios in my domain.

How would you implement this scenario?

Thanks, Dave

Update

After reading Theo's answer, I think I will go with option #2 and create a specialised SearchRepository within my infrastructure geared towards these scenarios. The application layer (WCF services) can then call these repositories that just populate the summary DTOs directly rather than mapping domain entities to DTOs.

**** Update 2 ****

Although I asked this over a year ago I thought I'd just add that I've since discovered CQRS which is aimed at solving this exact problem. Udi Dahan (http://www.udidahan.com/) and Greg Young (http://codebetter.com/gregyoung/) have written a lot about it. If you are creating a distributed application with DDD, CQRS is for you!

I think that you only want to display summarized information. These bits of summarized information are no entities or value objects of the domain model. They are only information, nothing more.

It is something like showing reporting information. If I deal with such things, I would not stick to the pure DDD approach. Your suggested options are OK, because it's getting your job done. DDD should be not treated as dogma. Think outside the box. Loosen up a bit DDD.

But be aware that you are just creating informational values outside the model for displaying purpose. So if a user selects one bit of information to make some operation with it (which is defined in the domain model), you need to extract the identifier from the informational values and pull out the entity/value object/aggregate from a repository.

I strongly recommend this video: Eric Evans: What I've learned about DDD since the book. If you read his book, you really should see the whole video. Pay very close attention at about time 30:00 where Eric Evans himself talks about aggregates and refers to the problem you currently have.

I would:

1. Return a different object that represents a view of my object for display, e.g. CustomerInfo.
2. Return a DataTable. Often a generic container is the easiest and best way to go.

If the T in your generic base repository is a Customer, then I think you are mis-applying the concept of aggregate roots, though I'm not a strict Evansangelist. I would design a repository for Customer that returned any data that logically or comfortably groups with Customer, including DataTables or read-only objects that are views of Customer data.