Skip to main content

Bounded Contexts as Service Boundaries

What This Concept Is​

A bounded context (Domain-Driven Design, covered in S7 M3) is a region of a system where a particular model and ubiquitous language apply consistently. Inside the context, words like "order", "customer", or "product" mean exactly one thing. Between contexts, the same word may mean different things -- and that is fine, because the contexts translate at their boundary.

The claim of this concept: bounded contexts are the strongest available candidate for service boundaries. A service whose scope equals one bounded context tends to have the right cohesion, the right team alignment, and the right data ownership. A service that cuts across contexts, or that covers only part of one, usually fails.

Why It Matters Here​

When microservices decompositions fail, the post-mortem almost always shows that the seam was drawn on a technical axis (by entity, by layer, by "thing it operates on") rather than on the semantic model. Bounded contexts give you a decomposition axis that is aligned with business meaning, which is also the axis along which the business will ask for changes.

Concrete Example​

In an e-commerce company, the word product appears in at least three contexts with different meanings:

  • Catalog context. A product is a marketable entity: title, description, images, SEO metadata, category tree, price display.
  • Inventory context. A product is a stockable SKU: warehouse quantities, reorder points, lead times.
  • Fulfillment context. A product is a shippable unit: dimensions, weight, hazmat flags, courier constraints.

If you model one giant Product entity, three teams fight for one table and one deploy. If you honor the bounded contexts, three services emerge naturally:

  • Catalog Service -- owns catalog_db. Aggregates: Product (marketing view), Category, Brand.
  • Inventory Service -- owns inventory_db. Aggregates: StockItem, WarehouseLocation, Reservation.
  • Fulfillment Service -- owns fulfillment_db. Aggregates: ShippableUnit, Shipment, PackagingRule.

Each service has its own definition of "product" tailored to its context. Cross-context references use stable IDs (a product_id) and each service stores only the attributes it actually uses.

Common Confusion / Misconception​

"Bounded context = microservice." Not always. Some bounded contexts are small enough to share a service. Some large contexts may be split into multiple services for team or scale reasons. The rule is one bounded context per service, possibly multiple services per context -- never the reverse. A single service that spans two bounded contexts is the root cause of many coupling problems downstream.

Second confusion: treating the bounded context as a data boundary only. It is also a language boundary. The API vocabulary on the outside of the service should match that context's ubiquitous language, not the union of all contexts.

How To Use It​

  1. Before drawing any service boundaries, draw the context map: the contexts you already have or intend to have, and the relationships between them (partnership, customer-supplier, conformist, anticorruption layer).
  2. For each context, identify the aggregates and their invariants.
  3. Propose a service (or small cluster of services) per context. Name the service after the business capability the context delivers, not after the data.
  4. For every cross-context interaction, decide whether it is synchronous (sync API + ACL) or asynchronous (events with translated payloads).
  5. Check: does any proposed service span two contexts? If yes, split.

Check Yourself​

  1. Why do three services named "Product Catalog", "Product Inventory", and "Product Fulfillment" work better than one "Product Service"?
  2. What is the difference between a bounded context and a microservice?
  3. If two teams disagree about what "customer" means, which pattern (ACL, OHS, published language) helps?

Mini Drill or Application​

Pick a domain you know (e-commerce, banking, SaaS, healthcare). In 15 minutes:

  • List the 3-5 bounded contexts you would draw.
  • For each, write one sentence of ubiquitous language: "In this context, X means ...".
  • For two contexts, name a shared term that means two different things.

You have just produced a context map draft. Everything else in cluster 2 builds from here.

How This Sits In The Module​

Concept 05 adds two more decomposition lenses (business capability, noun/verb) that often agree with contexts; when they disagree, you have a useful signal. Concept 06 lists the ways this goes wrong. Cluster 3 converts the boundary into data ownership and contracts.

Read This Only If Stuck​

Local chunks​

External canonical references​

Depth Path​

  • Vlad Khononov, Learning Domain-Driven Design (O'Reilly, 2021) -- chapter on context maps and integration patterns. Return here after the decomposition heuristics concept.
  • Eric Evans, Domain-Driven Design (2003), chapters 14-16 -- the original strategic-design text. Dense but still the reference.

Transfer: Context Maps Are Political Artifacts​

A context map is not just a technical document -- it is a political one. It says, "here is where our model is split and who owns each part." The hardest conversations in this space are not technical:

  • Two teams both think they own "customer." The context map forces a decision: either different contexts (with different "customer" definitions, translating at the boundary), or one context (with one team owning it, the other consuming).
  • A legacy team refuses to expose events. The map makes the ACL (anticorruption layer) explicit -- and the cost of running it visible.
  • A new product line claims it is "just a feature of Orders." The map reveals whether it is actually a new bounded context masquerading as a feature, which predicts its future pain.

Drawing the context map in a room with stakeholders and then committing it to version control (as an ADR or a dedicated context-map.md) is one of the highest-leverage architectural artifacts you can produce. It is also the hardest to produce honestly.

The S7 M5 discipline applies: this is a one-way door decision. Schedule it with the weight it deserves.

Context Relationships That Affect Service Design​

When two contexts touch, the DDD relationship type determines the contract shape:

  • Partnership. Both contexts evolve together, teams coordinate closely. Rare; often an anti-pattern in a microservices setup because it implies coordinated deploys.
  • Customer-Supplier. One context consumes another and has voice in the contract. Healthy for services; translates to CDC (cluster 3, concept 09) so consumers can drive provider evolution.
  • Conformist. Consumer accepts the provider's model as-is, no voice. Acceptable for generic subdomains (use the vendor's model).
  • Anticorruption Layer (ACL). Consumer translates provider's model into its own. Use this when the provider's model leaks abstractions you do not want downstream.
  • Open Host Service (OHS) + Published Language. Provider exposes a stable, well-documented public model. This is what most microservices aim for.
  • Separate Ways. The two contexts share no meaningful integration. Sometimes the right answer: forcing integration where none exists creates accidental coupling.

When you draw your service boundaries, annotate each cross-service edge with one of these labels. If most edges are "Partnership", you have a coordination problem that microservices will not fix.

A Sample Context Map Fragment​

The labels give you contract shape:

  • Customer-Supplier -> sync API or events, versioned, consumer-driven contract test required.
  • Conformist (vendor) -> consume vendor's SDK/shape directly.
  • ACL -> custom translator inside your service; legacy system's model never leaks past.

Why Teams Get This Wrong​

Engineers tend to draw services by technical layer ("API service", "worker service", "ML service") because that is how the codebase is laid out. Business analysts tend to draw them by entity ("Customer service") because that is how requirements documents are written. Neither axis is the right one.

The bounded-context axis is uncomfortable precisely because it does not match the org chart or the existing code. That discomfort is the signal. If your proposed decomposition matches neither your current file structure nor your current team structure, it is probably correct, and you will need to reshape both to match.