I’m struggling with aggregates and aggregate roots. I have a natural aggregate root which works for about 60% of the user requests. I.e. those requests naturally apply to the aggregate root.
Within my aggregate I have another entity which can only exist as a member of the aggregate root. Users, however, will be told about this other entity object. It will sometimes make sense, conceptually, for users to operate on this non-aggregate root object directly.
So, I think I have a couple of options:
- They can they both be aggregate roots depending on which operation is being requested by the user.
- All operations have to go through the top level aggregate root.
Note that the top level aggregate root will hold a collection of this other entity.
Example:
Main aggregate root: Car
Second entity: Seat (a Car has either 2 or 4 seats depending on type). In my domain seats can only exist as part of a car.
Most operations in the domain are at the Car level. So that will be a good candidate for aggregate root. However, (and I’m struggling for examples here), some operations will be at the seat level, e.g. SpillCoffee, ChangeFabric, Clean….
Can Seat and Car both be aggregate roots? Or should I always start with Car?
Thanks
The idea of an aggregate is to guarantee consistency, being the root responsible for data integrity and forcing invariants.
Suppose there’s a rule like “The fabric of all seats must be the same”, or “”you can only spill coffee on the seat if there’s someone inside the car”. It will be much harder to enforce these, once the clients will be able to change the fabric separately, or these invariants will need to be forced outside (danger zone).
IMHO, if integrity or forcing invariants is not an issue, then aggregates are not really needed. But, if it is necessary, my advice is to start everything with the car. But always think of the model. If there are invariants like these, then who enforces these invariants? Then try passing this idea to the code, and everything should be fine.