Bounded Context

A model is only valid inside an explicit boundary; the same word can mean different things in different contexts.

The same word can mean different things in different contexts, so each keeps its own model and they translate at the boundary.

To an executive

The same word can mean different things to sales, billing and support. Forcing one definition on everyone causes confusion and rework, so clear boundaries cut cost and mistakes.

To an engineer

Draw explicit boundaries within which each term has one meaning. Translate deliberately between contexts, and record the relationships on a context map rather than sharing one model.

The idea

Eric Evans, in Domain-Driven Design, observed that a single unified model of a large business does not hold together. "Customer" means a prospect with a pipeline to sales, an account with payment terms to billing, and a person with open tickets to support. Forcing one definition on all three produces a model that fits none of them.

A bounded context is the explicit boundary inside which one model, and one language, is consistent. Inside it, every term has one meaning. Across boundaries, the same word may mean something else, and that is fine as long as the translation is deliberate.

The relationships between contexts are drawn on a context map: shared kernels, customer–supplier relationships, conformists, anti-corruption layers and published languages. The map makes integration a design decision rather than an accident.

Why it works

Consistency is only affordable in a small space. Keeping one model coherent needs people who talk to each other often. A boundary sized to one team makes that possible.

Language and model stay aligned. Within a context, the words the business uses match the names in the code, so conversations and code change together.

Change stays local. When billing redefines what an account is, only billing and its translators change. Other contexts keep working.

Where it applies

Service and team boundaries, where a bounded context is a strong default for what one team owns end to end.
Enterprise data models, where a canonical model is being proposed or is already failing under its own weight.
Migrations, where a legacy system's model should be kept out of the new one through translation.
Mergers and platform consolidations, where two organisations use the same terms differently.

How to apply

Listen for overloaded words. When "order", "product" or "customer" causes arguments, you have probably found a boundary.
Draw the contexts and owners. Give each context one team and one consistent language.
Map the relationships. For each pair of contexts that integrate, decide the pattern: shared kernel, customer–supplier, conformist or anti-corruption layer.
Translate at the edges. Keep each context's internal model private, and publish only what other contexts need.

Example scenario

An enterprise canonical "Product" model had grown to hundreds of attributes to satisfy every department. Catalogue cared about descriptions and images, inventory about locations and stock, pricing about price lists and rules. Every change needed sign-off from six groups, and most releases were blocked on someone else's field.

The architects split it into catalogue, inventory and pricing contexts, each with its own lean Product model and a shared product identifier. Events carried only what the other contexts needed, and each team translated at its edge. All three teams could change their own model without waiting for the others.

Questions to ask

When we say this term, does every team in the room mean the same thing by it?
Which team owns this model, and who decides when its language changes?
Where does translation happen between these two contexts, and who maintains it?

When not to use it

Small systems with one team and one vocabulary, where explicit contexts add ceremony without benefit.
Generic subdomains such as authentication or email delivery, where you should adopt a product's model rather than design your own.

How it misleads you

Contexts drawn too small recreate coupling through integration: every business operation spans five contexts and needs a distributed transaction. Contexts drawn along technical layers, such as "the database context", are not bounded contexts at all. Draw boundaries around coherent business language and ownership, and expect to move them as you learn.