Aggregates vs Entites

[briansan...@gmail.com]

Greetings,

I currently maintain/enhance a monolithic application and am working on translating some pieces to CQRS. This is a multi-enterprise application. You are a user, who belongs to a company, who can be associated to one or more enterprises. Simply put, when you have an enterprise, it means that you can have certain things of your own (eg. Approval Paths, Brands, Contact Types, Divisions, etc...). An Approval Path, for example, is something that would be used to send something thru an approval process. From the UI, I might create the path (ie. give it a unique name) and then add steps (first it goes to my manager, then it goes to their manager, etc...). I might even reorder steps. At first glance, it would seem that Enterprise is the aggregate root, and Approval Path is an entity. But, OTOH, it seems like Approval Path might be its own aggregate. I mean, anytime I want to make a change to the approval path, I would need to specify which enterprise even though it seems like the approval path could stand on its own. The enterprise would ensure that the names are unique. Does it seem like I am approaching this correctly? Thanks.

[mynkow]

Hello,

try to design small aggregates. By small I do not mean less code but the amount of events which the aggregate produces during its lifetime. Something which I always do is to foresee how many event my aggregate will have in 3 months, 6 months even years. If the number is beyond hundreds then I am trying to do it differently.

In your case, having an aggregate with Enterprise entity as a root and everything else as entities inside smells. Well, ofc I have no idea of the domain you are building so you could ignore that comment.

Also, it is perfectly fine to send the ID of the Enterprise entity/AR to other aggregates and persist it.