What Are Aggregates, Roots, Entities, and Value Objects in DDD?

In Domain‑Driven Design (DDD) an aggregate groups related entities and value objects within a bounded context , forming the basic unit for data modification and persistence.

Key questions: Is an aggregate merely a tree of closely related objects? Is there a practical limit to the number of objects inside it? Can aggregates reference each other recursively and modify objects during traversal? What do invariants and consistency boundaries really mean?

1. Meaning of Aggregate

Just as society is built from individuals, aggregates organize entities (business objects with attributes and behavior) and value objects (attribute collections describing state) into a cohesive unit that enforces data consistency when implementing shared business logic.

Entities usually correspond to business objects with attributes and behavior.

Value objects are collections of attributes that describe an entity’s state and characteristics.

Aggregates have a single aggregate root and a context boundary defined by business responsibilities and high cohesion. The root coordinates internal entities and value objects and serves as the external interface for other aggregates.

2. Aggregate Root

The aggregate root is the “leader” of the organization: it is an entity with a global unique identifier, its own lifecycle, and the authority to enforce business rules within the aggregate. It also acts as the entry point for external requests, linking other aggregates via its ID.

As an entity, it holds attributes and business behavior.

As the manager, it coordinates entities and value objects according to fixed business rules.

3. E‑commerce Example

Typical e‑commerce aggregates include Inventory , Product , and Order . In the order aggregate:

Order is the aggregate root.

Order items (product ID, name, price, quantity) are entities because they are a collection referenced by the order.

Shipping address is a value object – it is replaced as a whole and has no identity.

4. Insurance (Policy) Case Study

Use event‑storming to list all entities and value objects involved in the underwriting process (policy, insured object, customer, etc.).

Select aggregate roots (e.g., Policy and Customer ) by checking for independent lifecycle, global ID, and responsibility for creating/modifying other objects.

Group related entities/value objects around each root to form two aggregates: Policy and Customer .

Draw the reference and dependency diagram inside each aggregate.

Place both aggregates into the same bounded context based on business semantics.

5. Design Principles

Small aggregates reduce concurrency conflicts, lock contention, and improve scalability.

Identify true invariants (business rules that must always hold) to decide what belongs together.

Within an aggregate, enforce strong (transactional) consistency; between aggregates, use eventual consistency via domain events.

Reference other aggregates only by their root ID, never by direct object reference.

Avoid cross‑aggregate domain‑service calls and database joins; instead, let the application layer coordinate via asynchronous events.

6. Modeling Small Aggregates

If an aggregate becomes too large, it may cause performance bottlenecks. A “small” aggregate may contain only a global identifier and a minimal set of attributes needed for its invariants. Use root entities to hold the smallest necessary attribute set, and model replaceable parts as value objects.

7. Consistency Boundaries

All data inside an aggregate must obey its invariants; anything outside the boundary is unrelated. Example code illustrates a simple invariant: c = a + b When a = 2 and b = 3, c must be 5. Violating this breaks the aggregate’s consistency.

AggregateType(
    int a;
    int b;
    int c;
    operations ...
)

8. Summary of Core Concepts

Aggregate : high cohesion, low coupling, smallest unit for microservice decomposition; may contain multiple aggregates.

Aggregate root : entity with global ID, sole entry point, coordinates internal objects, exposes ID for inter‑aggregate collaboration.

Entity : has identity, mutable state, lives inside an aggregate, usually persisted.

Value object : no identity, immutable, represents a set of attributes; often embedded within the root.