11

In my application, I have a listing of information that is deducted from a query that combines information from several entities. In itself, a very common situation.

Now, the corresponding repository method should return a list that contains items of an appropriate type. Clearly, choosing an entity is not appropriate because the information we're dealing with spans across multiple entities. I guess the same applies when querying partial entities. Creating a new entity doesn't make sense either because it would only muddle the model.

I was thinking in the direction of something like creating a DTO in the application layer because the particular query really is there to satisfy an application requirement and not a business requirement.

This essentially leads to introducing the notion of application specific repositories and a dependency on the application layer from those specific repositories.

Somehow this doesn't feel right. Is there a more appropriate approach/pattern I could use here?

Sandor Drieënhuizen
  • 1,155

1 Answers1

11

IS this a read-only situation? Because that's what it sounds like.

If you're doing DDD, then whenever you need to update/create something in your app you're going to go through the domain model because that is going to contain all of your business logic and validation.

However, there are times in your application when you just want to aggregate together a bunch of data to display to a user in a read-only fashion. In this case, exposing that data through a DTO via a service layer seems perfectly acceptible to me.

I wouldn't do it in the application layer though. I'd expose it as a service facade around my repositories. Let the facade deal with calling the respositories, aggregating the data and generating the DTO. From the application's point of view, it's just getting data with a call to a service. Nothing fancy.

Chris Holmes
  • 2,254
  • 1
    +1 for facading via the service, keeping data access useful but isolated is key. – Wyatt Barnett Mar 31 '11 at 21:21
  • 1
    The separation of queries from the domain can be considered command-query responsibility segregation (CQRS). Though in this case I wouldn't expect you to apply CQRS across your codebase, but simply separate this query out from your domain. You can use a service, or more commonly a query object, which as Chris said would wrap the repositories involved. It may also be worth considering bypassing the repositories and going straight to the data source, if this is a performance critical area and your repositories are heavy. – quentin-starin Mar 31 '11 at 22:21
  • 4
    What if the query depends on a lot of business logic to filter out the data? – andho Jul 17 '11 at 15:40
  • For @andho argument, I would do it in application layer. However, damn, your explaination convinced me to use DTOs (Commands/Data) as in IDDDSample but now onion architecture really looks hard with a lot of headache. This is alternative to what's used in DDDSample app – Anddo Jul 14 '20 at 23:08