I'm trying to model online shop catalog using Domain Driven Design.

There are three main concepts I have right now: Product, Category, Attribute.

Attribute is a characteristic of a product. For instance things such as color, weight, number of CPU cores etc. There are attributes which possible values are fixed, for instance "condition" - can be new or used. Some of them are within some range of values, for instance "number of CPU cores". Some are freely created like "color".

Category have required attributes which every product within that category needs to have, and optional ones. Categories can have parent categories.

Product belongs to a single category which needs to be a leaf category(no children categories).

Now the problem I have is to model these three concepts as aggregates.

One option is to have three different aggregates: Product, Attribute, Category.

Product will have it's attribute values(each with parent id to Attribute AR). Attribute will be in different types(fixed, freely choosen, range). Category will have a list of IDs of Attributes which are required, and list of IDs

The issue here is that whenever I need to create a new product I would need to check if it has all of the required attributes, check the values, and then store the product. This validation would span three aggregates. Where should it go ? It should be domain service ?

Other option is to have 2 AR. Category, with it's products and Attributes. The issue here is again validation of correct values for a single attribute added to a product. The other huge issue I see here, is that I should fetch the whole aggregate from the repository. Given that category can have hundreds of products, I don't think that's a good idea. However it makes sense as a conceptual whole, as If I would like to delete a category, all of it's products should be deleted as well.

What I am missing here ?

  • Why would you model Attribute as an aggregate root? Sounds more like a Value Object; the product entity can have a collection of Attribute VO’s.
    – Rik D
    Aug 23, 2020 at 13:19
  • I wanted to model it as an AR because it has an identity - it should only one attribute: "number of CPU cores". Attribute Value itself is a VO. It can be on Product. I was thinking about having Attribute Value object with ID of the Attribute(parent) and value. This way it can be on Product. Aug 23, 2020 at 13:24
  • I think you are right - if Attribute is a Value Object it can be on both Category list of required and optional characteristics, and it can be on product as well. What's more Product can hold references to Attributes, and attributes can hold it's values. This way during creation the validation would be held in Attribute value object. Aug 23, 2020 at 13:31
  • It sounds like you're trying to apply DDD to a data modelling problem - keep in mind that DDD principles are intended to help for complex behaviour within a domain model rather than complex data structures. DDD has nothing particularly useful to contribute toward persistence/data layer data issues. If the most complex behaviour you need to model here are standard database operations and data validation, then really all of your complexity exists in the data layer, in which case you may not even need the DDD concept of a 'domain model' at all. Aug 23, 2020 at 15:32
  • DDD is used to create a useful abstraction of the functional requirements of a system. Your post is focused only on modeling the data. It is therefore not possible to synthesize a reasonable domain model given the requirements you have denoted. Aug 23, 2020 at 15:54


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.