Aggregate Boundaries in Go: One Rule That Beats 90% of DDD Books

Book: Hexagonal Architecture in Go
Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

You've seen this Slack thread. A team is six months into a "DDD rewrite," there's a 400-page book on someone's laptop, and the open question is still: should Inventory be inside the Order aggregate, or outside? Senior engineers argue both sides. The PR has 47 comments. Nothing ships.

Here is the rule that resolves 90% of those threads:

One aggregate change per database transaction. Everything else is eventually consistent.

That's the rule. Vaughn Vernon defended it across a three-part paper called Effective Aggregate Design (Part 1, Part 2, Part 3). Most DDD books bury it under 200 pages of context maps and ubiquitous language. In practice, it is the only aggregate-design rule worth memorising before you write any Go.

Why This One Rule Carries So Much Weight

The aggregate boundary is the consistency boundary. That phrase sounds abstract until you read it as a transaction guarantee:

Inside the boundary: invariants are kept transactionally. Order.Confirm() either commits with all line items, the total, and the new status — or it commits none of them.
Outside the boundary: invariants are eventually consistent. The warehouse system finds out that an order was placed after the order commits, via a domain event.

If two aggregates need to change in lockstep, you have two bad options. One is wrapping them in one database transaction across two aggregate roots. That forces a single database, blocks under contention, and locks you out of any future split. The other is distributed transactions, a coordination cost most teams cannot afford and most ORMs cannot model honestly.

The rule cuts the question in half before you write code. Can these two things tolerate a few milliseconds of lag between them? If yes, they belong in separate aggregates and you talk to them via events. If no, they belong inside the same aggregate and you hold the line on transactional integrity.

The Test: "An Order Is Its Lines"

When a domain expert says "an order is its lines," they are telling you the consistency boundary. An order with no items is nonsense. An order whose total disagrees with the sum of its line items is a bug, not a state. Those are invariants — they must always hold.

So Order and LineItem go in the same aggregate. The aggregate root is Order. Outside callers never touch a LineItem directly. They go through Order.AddItem(...), which keeps the total in sync.

package order

import (
    "errors"
    "time"
)

type Status string

const (
    StatusDraft     Status = "draft"
    StatusConfirmed Status = "confirmed"
    StatusCancelled Status = "cancelled"
)

type LineItem struct {
    sku      string
    quantity int
    price    Money
}

func NewLineItem(
    sku string, qty int, price Money,
) (LineItem, error) {
    if sku == "" {
        return LineItem{}, errors.New("sku required")
    }
    if qty <= 0 {
        return LineItem{}, errors.New("qty must be > 0")
    }
    return LineItem{
        sku: sku, quantity: qty, price: price,
    }, nil
}

func (li LineItem) Subtotal() Money {
    return Money{
        amountCents: li.price.amountCents *
            int64(li.quantity),
        currency: li.price.currency,
    }
}

LineItem is a value object inside the aggregate. The aggregate root owns the slice and is the only thing that mutates it.

type Order struct {
    id        string
    status    Status
    items     []LineItem
    total     Money
    createdAt time.Time
}

var (
    ErrEmptyOrder       = errors.New("order has no items")
    ErrAlreadyConfirmed = errors.New("order already confirmed")
    ErrNotDraft         = errors.New("only draft orders accept items")
)

func (o *Order) AddItem(item LineItem) error {
    if o.status != StatusDraft {
        return ErrNotDraft
    }
    newTotal, err := o.total.Add(item.Subtotal())
    if err != nil {
        return err
    }
    o.items = append(o.items, item)
    o.total = newTotal
    return nil
}

func (o *Order) Confirm() (Event, error) {
    if o.status == StatusConfirmed {
        return nil, ErrAlreadyConfirmed
    }
    if len(o.items) == 0 || o.total.IsZero() {
        return nil, ErrEmptyOrder
    }
    o.status = StatusConfirmed
    return OrderConfirmed{
        OrderID:     o.id,
        Total:       o.total,
        ConfirmedAt: time.Now(),
    }, nil
}

Three things matter here:

The line items live inside the order. There is no LineItemRepository. The repository works at the aggregate level — OrderRepository.Save(*Order) writes the order row and all its line item rows in one transaction.
Confirm() returns an event. The event records what happened so other aggregates can react to it later, outside this transaction.
The total invariant (total equals sum of subtotals) is enforced by the only path that mutates items. There is no setter that can break it.

The persistence layer follows the same shape. One transaction, one aggregate.

package postgres

import (
    "context"
    "database/sql"

    "myapp/order"
)

type OrderRepo struct {
    db *sql.DB
}

func (r *OrderRepo) Save(
    ctx context.Context, o *order.Order,
) error {
    tx, err := r.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    if err := upsertOrderRow(ctx, tx, o); err != nil {
        return err
    }
    if err := replaceLineItems(ctx, tx, o); err != nil {
        return err
    }
    return tx.Commit()
}

The transaction touches one aggregate's tables. That's the rule, made concrete.

Inventory Is a Different Aggregate, So It Is Eventually Consistent

When an order is confirmed, the warehouse needs to decrement stock. The naive instinct is to do it in the same transaction: confirm the order and decrement inventory, atomically. That feels safer. It is not.

Confirming an order and decrementing inventory are different consistency boundaries:

An order's invariants (status transitions, total integrity, line-item rules) belong to the order's lifecycle.
Inventory's invariants (stock counts never go negative, reservations expire, a SKU's available quantity is total minus reserved minus committed) belong to the warehouse's lifecycle.

Forcing them into one transaction means every order confirmation locks rows in two domains. Under load, you get contention, deadlocks, and the slow death of a service that used to be fast. Worse: the day someone wants to shard inventory by warehouse or move it to a separate service, the transactional coupling has to be ripped out everywhere.

Two aggregates. One emits an event. The other reacts.

package inventory

import (
    "context"
    "errors"
)

type SKU string

var ErrInsufficientStock = errors.New("insufficient stock")

type Stock struct {
    sku       SKU
    available int
    reserved  int
}

func (s *Stock) Reserve(qty int) error {
    if qty > s.available-s.reserved {
        return ErrInsufficientStock
    }
    s.reserved += qty
    return nil
}

The application service for inventory listens for OrderConfirmed events and reserves stock. Each reservation is its own transaction, on its own aggregate.

package app

import (
    "context"
    "log/slog"
)

type InventoryHandler struct {
    stocks StockRepository
    log    *slog.Logger
}

func (h *InventoryHandler) On(
    ctx context.Context, evt OrderConfirmed,
) error {
    for _, line := range evt.Lines {
        s, err := h.stocks.Get(ctx, line.SKU)
        if err != nil {
            return err
        }
        if err := s.Reserve(line.Quantity); err != nil {
            h.log.Warn(
                "reserve failed",
                "sku", line.SKU,
                "err", err,
            )
            return err
        }
        if err := h.stocks.Save(ctx, s); err != nil {
            return err
        }
    }
    return nil
}

If reservation fails, the order is already confirmed. The system has to compensate by marking the order as awaiting-restock and notifying the customer. That sounds scary, but the alternative is worse. Distributed transactions across Order and Inventory would have failed at the database driver, with half-applied state and a stack trace nobody wants to debug at 2am.

The publish path is usually a transactional outbox. When Order.Confirm() returns the event, the application service writes the event to an outbox table inside the same transaction that saves the order. A separate process drains the outbox to Kafka, NATS, or whatever bus the system uses. Two transactions, atomic where it counts.

The Counter-Example: The Cart That Knows Too Much

Here is the failure mode the rule is designed to prevent. A Cart aggregate that holds live Product references.

type Cart struct {
    id    string
    items []*Product
}

type Product struct {
    sku   string
    price Money
    stock int
}

This looks innocent. It is not. Product is its own aggregate — it has its own lifecycle (price changes, stock movements, catalog updates). Holding a pointer to it inside Cart means:

Adding a Product to a Cart doesn't capture the price at the time of adding. The cart's total recalculates if a price changes.
Decrementing Product.stock from a checkout requires a transaction that spans Cart and Product. Two aggregates, one transaction. The rule is violated.
Two carts that hold the same *Product pointer can race each other through the Product's stock counter. Goodbye to in-process invariants.

The fix is small and important: a cart references the product by ID and by snapshotted value, not by pointer.

type CartItem struct {
    sku       string
    name      string
    unitPrice Money
    quantity  int
}

type Cart struct {
    id    string
    items []CartItem
}

func (c *Cart) Add(item CartItem) error {
    // ... invariant checks
    c.items = append(c.items, item)
    return nil
}

The cart now owns its own state. Adding a cart item snapshots the price the customer saw. Catalog updates do not silently change the cart's total. If you ever need fresh pricing, you do it explicitly. The application service fetches the current Product, builds a new CartItem, and the cart records the new value.

This is what the rule protects you from: aggregates that pretend the boundary doesn't exist.

The Three Questions That Place Any Boundary

Before you create a new aggregate (or argue about an existing one), answer these:

What invariant must hold transactionally? Write it as a sentence. "An order's total equals the sum of its line items." If the answer is "none," it is probably not an aggregate — it might just be a read model.
Can the world tolerate a small lag here? If it can, draw the line. The two sides become separate aggregates and they communicate through events.
Whose lifecycle is this? State that changes together belongs together. State that changes on different schedules, driven by different actors and different commands, belongs in different aggregates.

Three questions. Most of the "should X be inside Y?" debates collapse once those questions are answered honestly.

You can argue about ubiquitous language and bounded contexts forever and still ship a broken system. Get the consistency boundary right and the next argument is usually about something that actually matters.

If this was useful

The longer version of this argument — outbox patterns, repository design at aggregate granularity, where the application service belongs, and what to do when an aggregate genuinely needs to grow — is two chapters of Hexagonal Architecture in Go. Pairs with The Complete Guide to Go Programming if the language fundamentals are still settling in.

推荐订阅源

DEV Community