Key Principle
An Aggregate is a boundary drawn around exactly those Entities and Value Objects that must be consistent when a transaction commits, as determined by business invariants. Not "a cluster of related objects" — the boundary is driven by the question: what must be whole, complete, and consistent at the end of a single operation?
Four rules govern Aggregate design:
- Protect business invariants inside Aggregate boundaries — The invariant determines composition, not data relationships
- Design small Aggregates — Single root Entity plus Value Objects; grow only when invariants demand it
- Reference other Aggregates by identity only — Hold IDs, not object references
- Update other Aggregates using eventual consistency — Publish Domain Events; immediate cross-Aggregate consistency is the exception
"Modify and commit only one Aggregate instance in one transaction." (Chapter 5)
Why This Matters
Large Aggregates cause three cascading failures: slow loading from excessive data, high memory consumption, and frequent transaction failures from concurrent modification conflicts. The self-defeating irony: teams choose large Aggregates for "stronger consistency" but get less consistency because transactions fail more often.
Business stakeholders influenced by database thinking default to "everything must be immediately consistent." Counter with evidence: larger transactional boundaries mean more conflicts, which mean more failures, which mean less consistency in practice. (Chapter 5)
Good Examples
Invariant-driven composition: "When all Task instances have hoursRemaining of zero, the BacklogItem status must be set to DONE." (Chapter 5). Because this rule must hold at transaction end, Tasks belong inside the BacklogItem Aggregate. But BacklogItems do NOT belong inside the Product Aggregate, because no invariant requires Product and all its BacklogItems to be consistent in one transaction.
Right-sizing via Domain Expert conversation: Ask "how much time may elapse before X must react to Y?" Use exaggerated time frames ("could it wait a week?") to surface the real business threshold. The answer splits into immediate (compose into one Aggregate) and delayed (use eventual consistency via Domain Events). (Chapter 5)
Paper-system thinking: "Considering what the business would have to do if it ran its operations only by means of paper systems can provide some worthwhile insights." (Chapter 5). Most business processes already tolerate delay — they don't require atomic database transactions.
Counterpoints
Anemic Domain Model: Objects with getters/setters but no business behavior. Technical focus during modeling produces data-centric objects; business logic migrates to Application Services; the "domain model" becomes a persistence mapping layer. "Designing an Anemic Domain Model requires you to take on all the overhead of a domain model without realizing any of its benefits." (Chapter 5)
FP exception: In functional programming, separating immutable data records from pure functions is the norm, not an anti-pattern. The Anemic Domain Model critique applies specifically to OO contexts. (Chapter 5)
Over-abstraction trap: "Don't get taken in by this alluring, highly abstract implementation trap. Model the Ubiquitous Language explicitly according to the mental model of the Domain Experts." (Chapter 5). ScrumElement instead of BacklogItem breaks the language and forces special-case handling.
Key Quotes
"Modify and commit only one Aggregate instance in one transaction." — Vaughn Vernon, Chapter 5
"Designing an Anemic Domain Model requires you to take on all the overhead of a domain model without realizing any of its benefits." — Vaughn Vernon, Chapter 5
"Considering what the business would have to do if it ran its operations only by means of paper systems can provide some worthwhile insights." — Vaughn Vernon, Chapter 5
Rules of Thumb
- Start with single-Entity Aggregates; grow only when a business invariant demands it
- If two Entities don't share an invariant, they belong in separate Aggregates
- Hold IDs to other Aggregates, never object references
- Default to eventual consistency; justify immediate consistency with a specific invariant
- Ask Domain Experts about time tolerances, not developers about database transactions
Related References
- Domain Events and Event Sourcing - The mechanism for eventual consistency between Aggregates
- Bounded Contexts and Ubiquitous Language - The strategic boundary containing Aggregates
- Anti-Patterns and Failure Modes - Anemic Domain Model and over-abstraction