Aggregate Pattern

You're building an e-commerce system. A shopping cart contains items. Each item has a quantity, a price, and a discount. The cart has a total, a tax calculation, and a shipping estimate.

Now someone adds an item. You need to update the item list, recalculate the total, recalculate tax, and recalculate shipping. What if the total update succeeds but the tax recalculation fails? You have an inconsistent cart, the total doesn't match the actual items.

Or worse: two concurrent requests modify the cart. Request A adds an item. Request B removes an item. Both read the cart at the same time, both calculate a new total, both write. One update overwrites the other. Items and total are now out of sync.

The Aggregate pattern prevents this by treating the cart and all its related objects as a single unit. You can't modify items directly. You go through the cart, and the cart ensures everything stays consistent. It's the transactional boundary for a cluster of related objects.

Eric Evans introduced this concept in his 2003 book "Domain-Driven Design." Vaughn Vernon later expanded on it in "Implementing Domain-Driven Design" with detailed sizing guidance. The aggregate is the most misunderstood and most important DDD building block.

An Aggregate is a cluster of domain objects that are treated as a single unit for data changes. Every aggregate has an Aggregate Root, the single entry point through which all modifications must pass.

Rules of aggregates:

1. External objects can only reference the aggregate root, never internal objects directly.
2. All changes go through the aggregate root, it enforces invariants.
3. Within a single transaction, only one aggregate is modified. Cross-aggregate consistency is eventual.
4. Delete the root, delete everything inside the boundary.

The domain-driven design lesson runs rule 3 against a real PostgreSQL database: two clerks race to add a line to one order, and a version column on the root turns a silently broken limit into one visible conflict.