阅读中文版本

Aggregate Root

An aggregate root is the single entry point to a cluster of objects that must stay consistent together, defining the boundary for atomic changes.

Definition

An aggregate root is an entity that guards a consistency boundary, owning other objects and exposing them only through itself so that all invariants inside the boundary are enforced in one transaction.

It is used in domain-driven designs to decide what can change atomically and how concurrency conflicts are detected. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The root is the only object outside code may hold a reference to, and other aggregates are referenced by identifier so that each boundary remains independently consistent.

A well-sized aggregate loads and commits in one transaction, which keeps invariants enforceable without long-lived locks across many rows.

Trade-offs and alternatives

Oversized aggregates cause contention and force large loads, so the boundary should be the smallest set of objects that must be consistent at one instant. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that every entity in a model is an aggregate root. Another is that an aggregate must include everything related to it. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to referencing another aggregate by object instead of by identity and to making an aggregate of aggregate so large it locks the whole graph. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Repository Pattern, Unit of Work, Publish-Subscribe Messaging.