Boundaries from Bounded Contexts

## What a bounded context is In Domain-Driven Design, a **bounded context** is the explicit boundary within which a domain model and its vocabulary — the *ubiquitous language* — are internally consistent and unambiguous. Outside that boundary, the same word can legitimately mean something else. `Order` inside a **Sales** context might mean a cart of SKUs with pricing and promotions applied; the same word inside a **Fulfillment** context means a set of items to be picked, packed, and shipped from a specific warehouse; inside a **Billing** context it means a line-itemized invoice with tax and payment terms attached. These are not three views of one shared `Order` object — they are three different models that happen to share a name and a loose real-world correspondence. DDD's insight is that trying to force one canonical `Order` entity to satisfy all three consumers produces a bloated, constantly-contested model that nobody owns cleanly. ## Mapping one context to one service When decomposing a monolith (or greenfield system) into microservices, mapping one service to one bounded context lets each service own its model, schema, and language end-to-end without needing sign-off from other teams to evolve it. The mechanism for finding these boundaries is usually collaborative: 1. **Event storming sessions** surface the domain events, commands, and actors in a business process. 2. **Clusters of tightly-related events/entities** that share vocabulary and change together reveal where a bounded context (and thus a candidate service) begins and ends. 3. **Aggregates** — DDD's transactional consistency boundary — are then assigned wholly to one service; you never split a single aggregate's invariants across two services, because that reintroduces the very ambiguity bounded contexts exist to remove. ## The alternatives, and why they are weaker The alternative decomposition strategies are tempting but weaker. - **Splitting by database table** (a *data-centric* decomposition) produces services whose boundaries follow storage convenience rather than meaning — you end up with an *Orders service* and a *Customers service* that both need to agree on a shared, brittle definition of what an order or customer is, and every schema change becomes a cross-team negotiation. - **Splitting purely by org chart** (team ownership) can work when the org structure already reflects real domain seams, but org charts reshuffle for reasons that have nothing to do with the domain — a reorg can silently fracture a bounded context across two teams, or merge two contexts that should stay separate, without anyone noticing until integration pain shows up. ## The trade-off The trade-off of bounded-context alignment is **upfront cost**: finding the real seams requires real domain modeling effort (event storming workshops, talking to domain experts, iterating on the ubiquitous language) before writing a service. Teams that skip this and guess at boundaries from technical intuition alone often draw them in the wrong place: - **Too fine-grained** — chatty, coupled services that always deploy together, a *distributed monolith*. - **Too coarse** — a service that silently straddles two bounded contexts and re-introduces the ambiguous, contested model DDD was meant to prevent. The upside, when done well, is that each service boundary is a genuine semantic seam: changes inside one bounded context rarely ripple into another, so teams can evolve their service's internal model freely as long as they honor the translation contract (an anti-corruption layer or explicit context map) at the boundary. ## Failure modes Failure modes show up gradually rather than immediately. A service that was cleanly one bounded context at launch can drift as new features get bolted onto whichever service is *closest* rather than where the domain seam actually is — for example, adding loyalty-points logic to the Order service because it's convenient, when loyalty really belongs to its own context with its own rules and lifecycle. Over time this produces a service that speaks two ubiquitous languages internally, with naming collisions and a schema that no longer maps cleanly to any one mental model — a strong signal that the service needs to be split along the (now-clearer) context boundary. ## Where it shows up A concrete real-world pattern is the classic e-commerce decomposition. Catalog, Sales/Cart, Order Fulfillment, Billing/Invoicing, and Shipping are commonly separate bounded contexts and separate services, each with its own notion of `Order` or `Item`, stitched together via published domain events (`OrderPlaced`, `OrderShipped`) and explicit translation at each boundary, rather than one shared Order table queried by five services.