How to combine results of several repositories into a single result set without creating too much coupling in Domain?

Question

Imagine we have a four entities in the domain: Product that is produced, Technology that defines the product type, Material that is used during manufacturing process and Category to which the Material belongs. There are many Categories that can be nested within categories, the hierarchy depth has no limits. A Product can be made from various combinations of Materials.

Lets say we define Technology by adding or removing certain parent Categories. Then we create Product based on Technology and add/remove certain Materials that belong to Technology's Categories' subtrees.

If I wanted to render a list of top-level Categories with the Materials of the Categories subtrees belonging to a certain Product, my ProductRepository has to know the internal workings (e.g., nested tree implementation) of the CategoryRepository to be efficient. Otherwise I end up loading bunch of Collections and lose all the benefits of RDBMS.

What would be the correct way of reaching my goal in terms of Domain driven design?

Answer 1

I would like to place the method in CategoryRepository if you want some Category:

public interface CategoryRepository {
    List<Category> findWithMaterialsOfCategoriesSubtreesBeloningTo(ProductId productId);
}

And as far as I know, Knowing the structure of product is the only feasible and effcient way of implementing this.

Please allow me to quote Eric Evan's dddsample:

public interface HandlingEventRepository {


   /**
    * @param trackingId cargo tracking id
    * @return The handling history of this cargo
    */
    HandlingHistory lookupHandlingHistoryOfCargo(TrackingId trackingId);
}

What if the requirment changed to returning all HandlingEvent of an unshipped cargo? Then I have to join t_cargo and t_handling_event and filtering by "where t_cargo.status = ?".

Answer 2

If I wanted to render a list of top-level ...

"Rendering" is a presentation concern: it shouldn't affect the design of the domain model.

Thus, if you just need to show such kind of view, just use the best SQL query you can write.

As far as I can understand, the Product class provided by the repository should contain only the identifiers of the Materials and the materials should contain only the identifiers of the pertinent Categories. However this is true only if Products requires Categories to enforce their invariants!

However from your description of the requirements, I wouldn't adopt a DDD approach but a simpler CRUD one. As a rule of thumbs, you don't need DDD if you don't need to hire a domain expert to understand the business logic (and if you can reconduct all the business rules to RDBMS constraints).