Aggregate

The aggregate is where domain-driven design meets distributed systems, and it is the concept that most directly determines transactional design.

The rules are few and consequential. External references point only to the root; nothing outside holds a reference to an internal entity. All invariants that must hold immediately are enforced inside a single aggregate. And a transaction modifies one aggregate, with changes across aggregates handled asynchronously through events and eventual consistency.

That last rule is the one with architectural teeth, because it turns aggregate design into the decision about where strong consistency is required. An order with its line items as one aggregate means a line item cannot be added without the order's invariants being checked atomically. Order and customer as separate aggregates means updating both is eventually consistent, which forces the question of what happens in between.

The recurring design error is aggregates that are too large — pulling in everything related, which produces contention because every change to anything locks the whole cluster, and poor performance because the whole thing is loaded to change one field.

The sizing heuristic that works: an aggregate should be the smallest cluster that must be consistent immediately. If two things can be briefly inconsistent without a business rule being violated, they belong in different aggregates — and asking "would the business notice, and would it be wrong, if these disagreed for two seconds" resolves most cases.