Aggregates & Consistency

Entities and value objects don't float around loose - they cluster into aggregates, and this is the DDD concept with the most practical bite. An aggregate is a group of objects treated as a single unit for data changes, guarded by one entity - the aggregate root - that enforces the group's invariants. Get aggregate boundaries right and consistency becomes tractable; get them wrong and you either lock too much or corrupt your data.

The consistency boundary

An invariant is a rule that must always hold. In ledger-legacy: "an account's balance equals the sum of its postings," or "an order's total equals the sum of its line items." Someone must guarantee these rules hold after every change - and that someone is the aggregate root.

An aggregate is a cluster of entities and value objects that change together and share invariants. Its root is the one entity that outside code is allowed to touch; everything inside is reached through the root:

class Account {                                  // the AGGREGATE ROOT
    private final AccountId id;
    private Money balance;
    private final List<Posting> postings;        // internal entities - not exposed directly

    // the ONLY way to change the aggregate - the root enforces the invariant
    public void post(Money amount, String memo) {
        Posting p = new Posting(amount, memo, clock.now());
        this.postings.add(p);
        this.balance = this.balance.add(amount);   // invariant maintained atomically
        if (balance.isNegative() && !overdraftAllowed)
            throw new OverdraftException();        // rule enforced HERE, always
    }

    public List<Posting> postings() { return List.copyOf(postings); }  // read-only view out
}

Outside code cannot add a Posting directly - there's no account.getPostings().add(...) that bypasses the balance update. Every mutation goes through account.post(...), so the invariant "balance = sum of postings" can never be violated. The aggregate is the boundary of transactional consistency: one aggregate, one transaction, invariants always intact within it.

Rules of aggregate design

A few hard-won rules make aggregates work:

• Reference other aggregates by id, not by object. An Order holds a CustomerId, not a Customer object. This keeps aggregates small, decoupled, and independently loadable - and stops one transaction from accidentally dragging in half the object graph.
• One transaction modifies one aggregate. If a single operation must change two aggregates, that's a signal to use a domain event and eventual consistency between them (next lesson) rather than one giant transaction.
• Keep aggregates small. A big aggregate (an account holding all its transactions ever) means loading and locking huge object graphs. Prefer small aggregates; if postings grow unbounded, the aggregate boundary may be wrong.

Why "small" and "by id" matter

These rules are really about contention and coupling. Every change to an aggregate typically locks it (optimistically or otherwise). A giant aggregate is a giant lock - a bottleneck under load. Referencing other aggregates by object tempts you to modify them in the same transaction, blurring boundaries until "one transaction, one aggregate" collapses and you're back to ledger-legacy's everything-touches-everything mess.