Aggregate

Overview

An aggregate is the unit of consistency in domain-driven design. Everything inside is consistent after each transaction; everything outside is consistent eventually. The aggregate root is the only entry point.

How it works

Take an Order with line items. A rule says the total must never exceed the customer credit limit. Line items are only meaningful inside an order, so Order is the root and OrderLine is internal.

Order (root)
  |-- OrderLine
  |-- OrderLine
  customerId  --> reference by ID to Customer aggregate

class Order:
    def add_line(self, sku, qty, price):
        if self.total() + qty * price > self.credit_limit:
            raise CreditExceeded()
        self._lines.append(OrderLine(sku, qty, price))

The repository loads and saves the whole Order, often with a version column for optimistic concurrency. If shipping must react to an order being placed, the Order emits a domain event and a separate transaction updates the Shipment aggregate.

Pitfalls

• Making aggregates large because the data is related; relation does not imply a shared invariant.
• Modifying two aggregates in one transaction, which erodes the boundary.
• Exposing internal collections so callers mutate them directly.
• Designing aggregates from database tables instead of from invariants.
• Ignoring the version check, which allows lost updates.

Key takeaways

• Draw boundaries around invariants, not around relationships.
• One transaction modifies one aggregate.
• Reference other aggregates by ID.
• Prefer small aggregates and eventual consistency between them.