Aggregate

An Aggregate is the unit of behavior and consistency inside a Bounded Context. It owns a slice of the model that must change together, and it is the only place where a transactional rule about that slice can be enforced.

In ESDM, an Aggregate is the canonical kind of consistency unit: it accepts Commands, applies the rules of the domain, and produces Events that record what happened. Every Event in the model is published by exactly one Aggregate (or by another consistency unit), and every Command targets exactly one.

Identity, State, and Invariants

An Aggregate is identified by a single field – its natural key. The schema requires the Aggregate to declare which field that is, so the linter can verify that every Command and Event referencing the Aggregate carries the same identifier.

Beyond identity, an Aggregate has state – the data it carries between Commands – and invariants – the rules that must hold over that state. Invariants are the reason Aggregates exist. They are the place where "you cannot withdraw from an empty account" or "a round cannot end before it has started" lives, and they are checked at the moment a Command is handled.

When Not to Use an Aggregate

Not every consistency unit is an Aggregate. When the rule that must hold spans multiple Aggregates, a Dynamic Consistency Boundary is the right shape. When the behavior reacts to events over time without owning state of its own, a Process Manager is the right shape. When the goal is to expose data for queries rather than to enforce a rule, a Read Model is the right shape.

The Aggregate is the workhorse, but it is not the universal hammer. ESDM has all four shapes because each carries a different invariant, and conflating them turns into the kind of model that is hard to reason about a year later.