Domain-Driven Design: Tackling Complexity in the Heart of Software

Cluster the 
ENTITIES
 and 
VALUE OBJECTS
 into 
AGGREGATES
 and define boundaries around
each. Choose one 
ENTITY
 to be the root of each 
AGGREGATE
, and control all access to the
objects inside the boundary through the root. Allow external objects to hold references
to the root only. Transient references to internal members can be passed out for use
within a single operation only. Because the root controls access, it cannot be blindsided
by changes to the internals. This arrangement makes it practical to enforce all
invariants for objects in the 
AGGREGATE
 and for the 
AGGREGATE
 as a whole in any state
change.
It can be very helpful to have a technical framework that allows you to declare 
AGGREGATES
and
then automatically carries out the locking scheme and so forth. Without that assistance, the team
must have the self-discipline to agree on the 
AGGREGATES
and code consistently with them.
Example
Purchase Order Integrity
Consider the complications possible in a simplified purchase order system.
Figure 6.4. A model for a purchase order system
This diagram presents a pretty conventional view of a purchase order (PO), broken down into line
items, with an invariant rule that the sum of the line items can't exceed the limit for the PO as a
whole. The existing implementation has three interrelated problems.
1.

---

Invariant enforcement
. When a new line item is added, the PO checks the total and marks
itself invalid if an item pushes it over the limit. As we'll see, this is not adequate protection.
1.
Change management
. When the PO is deleted or archived, the line items are taken along,
but the model gives no guidance on where to stop following the relationships. There is also
confusion about the impact of changing the part price at different times.