Aggregates

## What an aggregate is An aggregate, in Domain-Driven Design's tactical patterns, is a **cluster of one or more entities and value objects** that are always loaded, modified, and persisted together as a single unit, because together they must satisfy a set of business rules — **invariants** — that cannot be verified by looking at any one object in isolation. Every aggregate designates exactly one of its member entities as the **aggregate root**: the sole object that code outside the aggregate is permitted to reference directly. Everything else inside the aggregate is private to it and reached only by first going through the root: - child entities - value objects - collections Think of an `Order` aggregate: the `Order` entity is the root, and `OrderLine` is a child entity that only exists, and only makes sense, in the context of a specific order. ## The rule, and the shortcut it closes The rule "reference other aggregates by ID, not by object reference" is the mechanism that makes the encapsulation above actually hold at the level of the whole application, not just inside one class. If an `OrderConfirmed` handler kept a live in-memory pointer to a `Customer` aggregate root, any code with access to that `Order` could reach `order.customer.loyaltyPoints -= 50` directly, mutating `Customer` state without going through `Customer`'s own root methods, its invariant checks, or its own transaction. The invariant that "loyalty points never go negative" would then depend on every caller behaving correctly rather than being enforced in one place. Holding a `CustomerId` value object instead — a plain identifier, often just a wrapped UUID or long — makes that shortcut structurally impossible: you cannot call a method on an ID, you can only ask a repository to load the `Customer` aggregate fresh, go through its root, and let it apply its own rules. ## Why the rule exists More broadly, DDD treats each aggregate as an independent consistency boundary and, in most implementations, an independent unit of persistence and locking (frequently one row or one root table plus its owned child rows, loaded and saved as a whole via one repository). If aggregates held direct references to each other, the object graph in memory would blur those boundaries: 1. loading one aggregate could transitively pull in an unbounded chain of others; 2. saving one could accidentally cascade writes into another's table; 3. two aggregates could end up needing to be locked and committed together, which defeats the purpose of splitting them at all. ID references keep the graph shallow: an `Order` aggregate stores `CustomerId`, not a `Customer`, so loading an `Order` never implicitly loads a `Customer`, and modifying an `Order` never risks writing to the customer table in the same transaction. ## The trade-off The trade-off is **indirection cost**. With object references, reading `order.customer.name` is a single in-memory hop; with ID references, displaying an order confirmation screen that needs the customer's name requires either: - a second repository call to load the `Customer` aggregate, or - more commonly in production systems, a read-side query/projection that joins the data outside the aggregate model entirely (a CQRS-style read model or a simple SQL join for display purposes only, never for mutating). Teams new to DDD often find this awkward and are tempted to "just" keep a reference for convenience. The failure mode this produces is **invariant leakage** — validation logic that should live inside one aggregate's root methods gets duplicated or half-implemented in whatever service happens to hold both references, and over time nobody can say with confidence which code path is allowed to change customer state. ## A second, subtler failure mode A second, subtler failure mode shows up in persistence frameworks like JPA/Hibernate: mapping an aggregate association as a lazy or eager @ManyToOne/@OneToMany object reference instead of storing a foreign-key-typed ID field silently reintroduces the object-graph problem the ID rule was meant to prevent — a save on the "outer" aggregate can cascade and flush changes into the "inner" one if cascade types aren't scoped carefully, corrupting the intended transaction boundary. This is why many DDD-aligned codebases deliberately map ID references as plain scalar/value-object columns rather than JPA associations, even though it costs an extra query when the related name or details are needed for display. ## Where it shows up A concrete, widely cited example is the classic e-commerce Order/Customer/Product split described in Eric Evans's original DDD book and popularized further by Vaughn Vernon's "Effective Aggregate Design" articles: - Order references CustomerId and each OrderLine references a ProductId, never the live Customer or Product objects; - precisely so that placing an order never risks corrupting catalog pricing or customer account state in the same transaction; - and so each aggregate can evolve, scale, and be sharded independently.