Tactical DDD

Implementation patterns within a bounded context. Tactical DDD answers: "How do we structure the domain model?"

Aggregates

An aggregate is a consistency boundary -- a cluster of domain objects that must be transactionally consistent.

Vernon's Four Design Rules

1. Model true invariants in consistency boundaries: Only include elements that MUST be consistent within the same transaction. If two entities don't share an invariant, they belong in separate aggregates.

2. Design small aggregates: ~70% of aggregates contain only a root entity with value-typed properties. Large aggregates create concurrency contention, scalability failures, and memory pressure.

3. Reference other aggregates by identity: Use ProductId not Product. Direct object references create accidental cross-aggregate transactions and prevent independent scaling.

4. Use eventual consistency outside the boundary: Domain events communicate across aggregates. One transaction = one aggregate. If you need to update two aggregates "atomically," reconsider your boundaries.

Aggregate Design Checklist

• Contains only elements sharing true invariants
• Root entity controls all access (no direct child manipulation)
• External references by ID only (no object graphs)
• Small enough for single-transaction performance
• Command produces events (in event-sourced systems) or mutates state (in traditional)
• Business rules validated in command handling, not in persistence layer

Common Aggregate Smells