Bounded contexts

A bounded context is an explicit boundary — usually a module or service owned by one team — within which a particular domain model applies and its terms have one precise meaning. It's the central strategic pattern of domain-driven design.

#Why one model doesn't fit all

In a large business, the same word means different things to different parts of the organisation. In food delivery, an "order" is:

• to ordering: the items a customer chose, with notes and displayed prices;
• to the restaurant: a ticket to cook, with prep time;
• to delivery: a parcel to move between two points, with a driver and an ETA;
• to billing: a financial transaction with fees, tax and settlement.

A single shared Order type serving all four grows dozens of fields, each meaningful to one team and confusing to the rest, and every change needs everyone's agreement. Bounded contexts give each area its own model — ideally its own words: Ticket, Delivery, Charge — containing only what that context needs. They share identifiers, not models.

#Relationships between contexts

Contexts still exchange information. A context map names how:

• Customer–supplier: an upstream context provides what a downstream one needs, and takes its needs into account.
• Conformist: the downstream adopts the upstream model as-is.
• Anti-corruption layer: the downstream translates a foreign or legacy model into its own at the boundary.
• Shared kernel: a small piece of model shared deliberately, changed only by agreement.
• Published language: a documented, versioned API or event schema.

Integration usually happens through APIs or domain events ("OrderPlaced"), never through one context reading another's tables.

#Finding boundaries

Look for where language changes — the same word with different meanings, or different experts. Look at business capabilities and at which rules must be consistent together. Team structure matters too: Conway's law means boundaries that cut across teams tend to erode.

Bounded contexts are the natural seams for modules in a modular monolith and, when justified, for services. Splitting along them — rather than by technical layer or by noun — is the difference between independent services and a distributed monolith. See the domain-driven design lesson and ubiquitous language.