Aggregate

Origin & evolution

Eric Evans introduced the aggregate in Domain-Driven Design (Addison-Wesley, 2003) as one of the tactical building blocks, alongside the entity and the value object💎Value ObjectEngineeringA DDD value objectView reference →. He defined it as a cluster of associated objects treated as a unit for data changes, with a root entity as the only member outside code is allowed to hold a reference to. Anything inside the boundary can be reached only by going through the root. When a change commits, every invariant across the whole aggregate must be satisfied.

The thinking sharpened around how big an aggregate should be. Vaughn Vernon's Effective Aggregate Design (2011) argued for small aggregates and a rule that has since become doctrine: reference other aggregates by identity, never by direct object pointer. One aggregate holds the id of another, not the object itself. That keeps each aggregate loadable and savable on its own, and it draws the transactional line cleanly: one transaction changes one aggregate.

The corollary is that consistency between aggregates is eventual, not immediate. A change in one aggregate propagates to others asynchronously, often by a domain event📡Domain EventEngineeringAn event published when something happens in the domainView reference →. The field accepted that trade because the alternative, sprawling transactions that lock half the model, scales badly and tangles the design. The boundary became the unit of both consistency and concurrency.

How it works in practice

Take an Order aggregate in a retail system. The root is the order; inside it sit OrderLine entities and a Money total. The invariant is that the sum of the lines always equals the recorded total, and that an order over £500 requires manager approval before it can be confirmed. Both rules are checked inside the aggregate when any command runs against it, so the order can never be persisted in a state that breaks them.

A Customer lives in its own aggregate. The order does not hold the customer object; it holds a customerId. When a line is added, the order recalculates its own total in one transaction and stays internally consistent. Updating the customer's lifetime-spend figure happens separately, triggered by an event the order emits once it is confirmed. If that update lands a few hundred milliseconds later, nothing breaks, because spend was never an invariant the order had to guarantee.

Aggregate vs. its neighbours

• Domain entity📦Domain EntityEngineeringA DDD domain entityView reference →: an entity has identity and a lifecycle, and it can exist on its own. An aggregate is a boundary drawn around one or more entities plus value objects, with exactly one of those entities promoted to root. Every aggregate root is an entity; most entities are not roots.
• Value object: a value object has no identity and is immutable, so it can sit inside an aggregate freely and be swapped without consequence. The aggregate decides which objects are reference-by-identity entities and which are by-value attributes.
• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference →: a context is a whole linguistic and model boundary that can hold many aggregates; an aggregate is a transactional boundary inside one context. The context says which model applies; the aggregate says which objects change together.

In the graph

In the Unified Product Graph, the aggregate is an engineering-region entity that records a consistency boundary in the domain model. A bounded_context_modelled_as_aggregateBounded Contextmodelled asAggregatehierarchy edge ties it to the context it belongs to, and aggregate_contains_domain_entityAggregatecontainsDomain Entityhierarchy and aggregate_contains_value_objectAggregatecontainsValue Objecthierarchy edges record what sits inside the boundary. Its behaviour shows up through aggregate_handles_commandAggregatehandlesCommandhierarchy and aggregate_emits_domain_eventAggregateemitsDomain Eventcausal, which connect the write side to the rest of the system. Modelling the aggregate explicitly makes the transactional line queryable: you can ask which entities must stay consistent together and which commands are allowed to touch them, rather than inferring the boundary from scattered code.