Question about modules

[augustolopez]

What would be the correct approach? single product module, nested modules e.g. product > variant, one module ea

[Sairyss]

There is no correct approach, it all depends on your business requirements and team structure.
For example:

• if a product feature is going to have a lot of complexity and there will be multiple teams working on each part, lets say "Inventory team" will work on SKU part, restock of products, etc., and a "Product Catalog" team will work on the products and it's variants, in that case you can create multiple modules so each team can work on it's own.
• on the other hand, if your application is relatively simple and there is not a lot of people working on it (for example a startup environment), you can put everything inside a single module, or even inside a single aggregate.
• or you can choose something in the middle

Also, your diagram looks more like a SQL table modelling, your domain can have different structure than your tables. For example tables in your DB can look the same way as in your diagram, but in your domain you can have a single aggregate that encapsulates all of it instead of having multiple aggregates (if that makes sense in your case).
Alternatively, If you don't have a lot of business logic for your products you may even skip using aggregates and model everything as a transaction script.
In the end you will need to play with it to understand all details and business requirements, maybe even refactor your solution a couple if times until you have what you want. There is no single correct way of doing it.

You can check out this videos for some extra tips:

• All our aggregates are wrong - relevant for large projects and microservices, don't do this if your project is small
• Don't be fooled! That's NOT an Aggregate in Domain Driven Design

[augustolopez]

Thank you so much for your detailed explanation