![From Gas Station to Google with Self-Taught Cloud Engineer Rishab Kumar [Podcast #158]](https://cdn.hashnode.com/res/hashnode/image/upload/v1738339892695/6b303b0a-c99c-4074-b4bd-104f98252c0c.png?#)
Repository returning multiple aggregates
A common DDD wisdom I encounter online is that your repository should not return more than one aggregate type. But I came across this passage from Vaughn Vernon's book "Implementing Domain-Driven Design": Use Case Optimal Repository Queries Rather than reading multiple whole Aggregate instances of various types and then programmatically composing them into a single container (DTO or DPO), you might instead use what is called a use case optimal query. This is where you design your Repository with finder query methods that compose a custom object as a superset of one or more Aggregate instances. The query dynamically places the results into a Value Object (6) specifically designed to address the needs of the use case. You design a Value Object, not a DTO, because the query is domain specific, not application specific (as are DTOs). The custom use case optimal Value Object is then consumed directly by the view renderer. It describes special finder methods that can return value objects containing multiple aggregates inside it. Which is interesting because I've never seen an example of this anywhere online. It's only described briefly and an implementation example was never given in the book. Am I misunderstanding this? Should this special finder method be placed into one of the existing single-aggregate repositories? Or should there be a special repository created for it?
A common DDD wisdom I encounter online is that your repository should not return more than one aggregate type.
But I came across this passage from Vaughn Vernon's book "Implementing Domain-Driven Design":
Use Case Optimal Repository Queries
Rather than reading multiple whole Aggregate instances of various types and then programmatically composing them into a single container (DTO or DPO), you might instead use what is called a use case optimal query. This is where you design your Repository with finder query methods that compose a custom object as a superset of one or more Aggregate instances. The query dynamically places the results into a Value Object (6) specifically designed to address the needs of the use case. You design a Value Object, not a DTO, because the query is domain specific, not application specific (as are DTOs). The custom use case optimal Value Object is then consumed directly by the view renderer.
It describes special finder methods that can return value objects containing multiple aggregates inside it. Which is interesting because I've never seen an example of this anywhere online. It's only described briefly and an implementation example was never given in the book.
Am I misunderstanding this? Should this special finder method be placed into one of the existing single-aggregate repositories? Or should there be a special repository created for it?
