Aggregate Boundaries, Bounded Contexts, and Data Ownership Across Services

Learning outcomes

A distributed architecture becomes fragile when every service can update every table or document. This lesson defines aggregate and bounded-context concepts from first principles, assigns authoritative writers, and shows why a shared database without ownership rules creates hidden coupling even when the schema itself looks convenient.

1. Aggregate means “change together to protect an invariant”

An aggregate is a consistency boundary around state that must be changed together to preserve a business invariant. It is not simply “a large document.” AtlasMart’s order aggregate can own order lines, totals, and lifecycle state because checkout rules often need those facts together. A product catalog entry has a different lifecycle. Payment authorization has another. If one command requires a distributed transaction across many unrelated aggregates, first ask whether the invariant is truly cross-boundary or whether the workflow can use reservation/compensation.

2. Bounded context means one meaning and one owner

A bounded context is a semantic boundary within which terms and rules have one consistent meaning. “Status” in Orders might mean placed, paid, shipped, cancelled. “Status” in Payments might mean pending, authorized, captured, refunded. Sharing a column named status does not merge those meanings safely. Assign one authoritative writer to each business fact. Other services can keep copies, but copies must record source/version and must not masquerade as ownership.

3. AtlasMart lab: expose shared-database ambiguity

The lab creates two snapshots of the same shared row. Orders cancels an order while Payments independently writes order_status=paid. Last writer wins, but neither service has a valid semantic basis to overwrite the other.

from copy import deepcopy

owners = {
    "order.status": "Orders",
    "payment.status": "Payments",
    "product.title": "Catalog",
    "customer.email": "Customer",
}

shared_row = {"order_id":"o-100","order_status":"placed","payment_status":"pending","version":1}

# Broken shared-database ownership: two services mutate the same business fact.
orders_snapshot = deepcopy(shared_row)
payments_snapshot = deepcopy(shared_row)
orders_snapshot["order_status"] = "cancelled"
payments_snapshot["order_status"] = "paid"  # Payment service infers an Orders-owned fact.
shared_row.update(orders_snapshot)
shared_row.update(payments_snapshot)
print("broken shared row order_status:", shared_row["order_status"])
print("owner registry says:", owners["order.status"])

# Repair: owner publishes facts; other contexts keep labeled copies/projections.
orders_authority = {"o-100": {"status":"cancelled","version":2}}
payments_authority = {"pay-100": {"order_id":"o-100","status":"captured","version":4}}
fulfillment_copy = {"o-100": {"order_status":"placed","source_version":1}}

event = {"type":"OrderStatusChanged","order_id":"o-100","status":"cancelled","version":2,"owner":"Orders"}
if event["owner"] == owners["order.status"] and event["version"] > fulfillment_copy[event["order_id"]]["source_version"]:
    fulfillment_copy[event["order_id"]] = {"order_status":event["status"],"source_version":event["version"]}

print("orders authority:", orders_authority["o-100"])
print("payments authority:", payments_authority["pay-100"])
print("fulfillment copy after event:", fulfillment_copy["o-100"])
print("copy is ownership:", False)
print("cross-context correction path: command owner or reconcile from owner events")

4. Ownership is also a security boundary

Database credentials should reinforce the semantic design. If Payments only needs an Orders projection, it should not receive unrestricted write access to Orders authority. Tenant identity must survive events and projections so a cross-context consumer cannot accidentally index one tenant’s facts under another tenant. Audit logs should record the acting service identity, command/request identifier, owner version, and resulting event so operators can reconstruct who changed authoritative state.

5. Integration without pretending boundaries remove coordination

Bounded contexts reduce accidental coordination; they do not eliminate legitimate cross-service workflows. Checkout still connects orders, inventory, and payments. The design question becomes explicit: which service owns each decision, what is reserved, which messages are idempotent, what compensation exists, and which temporary states are acceptable. Chapter 16 will explore those transaction/workflow choices directly.

6. Production judgment and bridge

Prefer clear ownership when teams deploy independently, facts have different lifecycle/invariants, or security boundaries differ. Avoid splitting an aggregate merely to match an org chart if every write then requires synchronous cross-service coordination. Plan migrations with shadow copies, versioned contracts, owner cutover, rollback, and reconciliation. The next lesson shows how derived read models can cross these ownership boundaries safely when they remain rebuildable copies.

Wrong approach: “shared database means shared ownership”

A shared physical database can be operationally convenient, but unrestricted multi-service writes create semantic ambiguity. The repair is not necessarily “one database per service”; it is explicit ownership, least-privilege writes, owner-mediated commands/events, source versions, and a migration path that preserves invariants.

Verification, cleanup, and production checklist

Verification is the deterministic program output plus the reasoning checks below. Cleanup is simply deleting the local lesson3.py file because the lab creates no external service or persistent database. In production, repeat the design with representative cardinality/skew, tail-latency, failure injection, tenant-isolation tests, restore/rebuild drills, migration rollback, and cost/capacity evidence before committing to a physical model.

References

Foundational statements are kept vendor-neutral. Version-sensitive examples use current official documentation and are labeled as examples rather than definitions.

• Martin Fowler — Bounded Context — Concise reference for bounded contexts and explicit model boundaries.
• Martin Fowler — DDD Aggregate — Reference for aggregate consistency boundaries.
• MongoDB — Embedded Data in Your Schema — Current example of grouping related data when one atomic aggregate boundary is valuable.
• PostgreSQL 18 — Privileges — Current relational reference for reinforcing ownership with least-privilege database permissions.