You're designing the aggregates for an event-sourced order-management system with CQRS. How do you decide where to draw each aggregate's consistency boundary, and what's the trade-off between making an aggregate bigger, to get more invariants enforced for free inside one transaction, versus splitting it and coordinating across the split via a process manager?

## The aggregate is the transactional boundary In domain-driven design terms adopted directly by Event Sourcing, an aggregate is the **transactional consistency boundary**: one aggregate instance corresponds to one event stream, and every command against it is checked with optimistic concurrency against an expected stream version, meaning only one command can successfully append to a given instance at a time. That single fact drives the design heuristic, articulated in depth in Vaughn Vernon's guidance on effective aggregate design: - model **true invariants**, business rules that must hold at every instant with no window where they can be false, inside a single aggregate; - anything that merely needs to **eventually be true**, and can tolerate being corrected shortly after a brief inconsistency, belongs in a separate aggregate coordinated through domain events and, where multiple steps are involved, a saga. ## Applied to order management Applied concretely to order management: a rule like 'an order line's quantity times its unit price must equal its recorded subtotal' is a true invariant, cheaply enforceable inside a single Order aggregate, since it only ever needs data already inside that aggregate. A rule like 'total inventory reserved across every order for a given SKU must never exceed warehouse stock' looks at first like it wants one combined Order-and-Inventory aggregate, but that would force every order in the entire system touching that SKU to serialize through one event stream. Instead, each SKU is modeled as its own Inventory aggregate holding its own reservation count, and Order coordinates with it via a saga that issues a `ReserveStock` command; for a brief window the system tolerates an order believing a reservation is pending while a concurrent order is racing for the same stock, resolved because the Inventory aggregate itself rejects a reservation that would push it negative, with the saga compensating on the Order side if that happens. ## The trade-off is symmetric The trade-off is symmetric. | Boundary | What you gain | What you pay | |---|---|---| | **A larger aggregate** | Its advantage is invariant simplicity: no explicit coordination code, no compensations, since one transaction guarantees the rule. | Its cost is contention: every command touching that aggregate instance serializes through one stream and one version counter, so throughput is capped by how many commands can pass through sequentially, producing a 'hot aggregate' problem, for example one enormously popular product's Inventory aggregate becoming a bottleneck during a flash sale, plus a growing event stream that makes replay and snapshotting progressively slower. | | **A smaller aggregate** | Its advantage is concurrency: independent instances scale and can be processed in parallel with no contention between unrelated entities, and streams stay short. | Its cost is coordination: any business rule spanning aggregates now needs an explicit saga, with the real engineering overhead of a state machine, compensating actions, idempotent command handling, and monitoring, plus a window of temporary cross-aggregate inconsistency the business must explicitly accept. | ## Getting the boundary wrong Getting the boundary wrong shows up differently in each direction. - **Modeling too coarsely**, for instance one Order aggregate holding an entire customer's full order history, produces frequent optimistic-concurrency conflicts and retried or failed commands under any meaningful concurrent load, visible in production as elevated error and retry rates concentrated on that one aggregate type. - **Modeling too finely** without building the necessary saga produces silent invariant violations instead, such as inventory going negative because nothing actually coordinates the cross-aggregate rule at all; this is a worse failure because it's data corruption rather than a visible, retryable error. ## The heuristics behind it This is the central design question addressed by Vernon's aggregate-design heuristics -- model true invariants, reference other aggregates only by identity rather than by object reference, and favor eventual consistency between aggregates by default -- and it's exactly why large e-commerce platforms typically model inventory per SKU, sometimes even per SKU per warehouse, as aggregates entirely separate from Order, using saga-based reservation workflows rather than one mega-aggregate that would serialize every order in the system through a single stream. ## Changing a boundary later In practice, teams rarely get the boundary perfectly right on the first design pass, and that has a cost specific to Event Sourcing: because events are immutable and the aggregate boundary is encoded in which stream an event lives on, splitting or merging aggregates after the fact is a genuine migration, not a quick refactor. It typically means writing a one-time transformation that reads the old, coarser stream and re-partitions its events into new, per-instance streams under a new identity scheme, then cutting every command handler and every projector over to the new boundary together, often behind a blue-green-style rollout so in-flight traffic isn't split across old and new boundaries mid-migration. That migration cost is exactly why it pays to load-test a candidate boundary against a realistic concurrency profile, for example simulating flash-sale-level concurrent orders against a single popular SKU, before committing to it in production, rather than discovering the hot-aggregate problem only after real traffic exposes it. ## Reference other aggregates by identity A related principle worth naming explicitly is that aggregates should reference each other only by identity, such as a plain SKU id stored on the Order aggregate, never by holding a live in-memory reference to another aggregate's full object graph. This isn't a stylistic preference: it's what keeps the two aggregates independently loadable, independently versioned, and independently scalable in the first place. An Order aggregate that held a direct reference to a full Inventory aggregate object would implicitly need both to be loaded and kept consistent together, quietly reintroducing the same coupling and contention that splitting them was meant to avoid.