In databases we have natural keys such as company code, client number, and order number. Then we have synthetic keys that are typically globally unique identifiers (GUID) or auto-incrementing numbers (IDENTITY).
It seams to me that we may need to make this same natural and synthetic distinction when it comes to aggregates in domain-driven design (DDD). The whole Aggregate Root (AR) concept makes it extremely difficult to define certain structures; especially when starting out with DDD. I find the reason being that some entities don’t work well as aggregate roots either:
- because the aggregate root seems to change depending on context; or
- the entity is not a natural fit for an aggregate root.
An example of a natural aggregate is something like Order
and OrderLine
. An order line can never exist without an order.
- Order has a Total that is calculated by summing the OrderLine Totals.
- Total on order cannot mean anything other than the total of the order lines.
An example of a synthetic aggregate is something like GrapeBunch
containing a GrapeStem
and a GrapeBerry
collection.
- GrapeBunch can have a Weight that is calculated by summing the Weight of each GrapeBerry in the collection and adding the Weight of the GrapeStem.
- The weight of the grape bunch cannot mean anything other than the sum of the grape berry weights and adding the weight of the grape stem.
An example of a problematic aggregate by using an aggregate root is GrapeStem
with a GrapeBerry
collection.
- What does the
Weight
on GrapeStem mean? - We could have another method called
TotalWeight
but this is confusing.