How do domain-driven design bounded contexts help you draw microservice boundaries correctly?

#Why "one microservice per table" fails

The most common mistake teams make when decomposing a monolith is drawing service boundaries around database tables, or around whichever team happens to own a piece of code, without asking what the boundary actually means. The result is a distributed monolith: services that are physically separate processes but semantically inseparable, calling each other synchronously in long chains because no single service actually owns a coherent piece of the business. Domain-driven design's bounded context is the tool that fixes this, because it draws boundaries around meaning rather than around infrastructure.

#What a bounded context actually is

A bounded context is an explicit boundary within which a domain model — its entities, its rules, its vocabulary — is internally consistent, and outside of which the same words may mean something entirely different. Consider the word "Customer" in an e-commerce company. In the Sales context, a Customer has a lead source, a deal stage, and a lifetime-value score. In the Support context, the same person is described by ticket history, an SLA tier, and satisfaction ratings. In the Shipping context, they are little more than a delivery address and a set of preferences. These are not three imperfect views of one "true" Customer object — they are three legitimately different models, each correct within its own context, and trying to force them into a single shared Customer entity is exactly the kind of god-object coupling that makes services impossible to change independently.

#Ubiquitous language

Inside a bounded context, the team — engineers and domain experts together — agrees on a single, unambiguous vocabulary, the ubiquitous language, and that vocabulary shows up literally in the code: class names, method names, event names. The discipline is not "pick good names," it is "the code and the business conversation use the exact same words," so that a domain expert can read a method signature and recognize their own process. When you find the same word being used by two groups of people to mean two different things, you have found a context boundary, whether or not anyone has drawn it on an architecture diagram yet.

#Context mapping: how bounded contexts relate to each other

Bounded contexts do not exist in isolation — they need to integrate, and DDD's context-mapping patterns describe the type of relationship, which is exactly the vocabulary an interviewer wants to hear:

• Shared Kernel — two contexts deliberately share a small, carefully governed subset of the model (typically a library of core value objects, like Money or Address). It is high coupling by design: any change to the shared kernel requires coordinating both teams, so it should be kept as small as possible.
• Customer–Supplier — one context (the supplier) produces something the other (the customer) depends on, and the two teams negotiate the supplier's roadmap and interface together, with the customer having real influence.
• Conformist — like customer–supplier, but the downstream team has no negotiating power (often because the upstream is a large external vendor or another org's legacy system), so it simply adapts to whatever model the upstream provides.
• Anti-Corruption Layer (ACL) — the downstream team builds an explicit translation layer that converts the upstream model into its own internal model, so that a messy, legacy, or third-party model never leaks its shape into the downstream service's core domain logic. This is the single most useful pattern for integrating with legacy systems or external vendors.
• Open Host Service / Published Language — a context exposes a well-documented, stable, versioned public contract intended for many consumers, so each new integration doesn't require a bespoke, one-off negotiation.
• Partnership — two teams evolve two contexts together with mutual, negotiated dependency and tight coordination, typically because their roadmaps are inherently linked.
• Separate Ways — the deliberate decision to not integrate, even duplicating a small piece of functionality in both contexts, because the coupling cost of integrating would exceed the cost of the duplication.

#Finding the boundaries in practice

The practical technique most teams use is event storming: get domain experts and engineers in a room, and map out the significant domain events across the whole business process on sticky notes, in the order they happen — OrderPlaced, PaymentAuthorized, InventoryReserved, ShipmentDispatched. Natural seams appear where the vocabulary shifts, where one group of stakeholders stops caring about the details and another group's expertise begins, or where the rate of change or scaling needs differ sharply. Those seams are your bounded contexts, and by extension, strong candidates for microservice boundaries — not because a diagram told you to split there, but because splitting there produces services that can each be understood, changed, and deployed by a small team without needing to renegotiate the meaning of a shared entity every time.

#Why this beats an ER-diagram decomposition

A classic entity-relationship decomposition optimizes for eliminating data duplication across the whole enterprise — one true Customer table, normalized, referenced everywhere. Bounded-context decomposition optimizes for something else entirely: team autonomy and clear ownership of a business capability, and it explicitly accepts some duplication (a denormalized customer-shipping-address projection inside the Shipping context, kept eventually consistent via events) as the price of that autonomy. That trade — duplication in exchange for independent deployability — is the single idea an interviewer is checking for when they ask this question.