ddd-bounded-context

One-line summary

A bounded context is the explicit boundary within which a single model — and the ubiquitous language that names it — is consistent and complete.

When to use this skill

• The same noun means two different things in different parts of the system ("customer" in sales vs "customer" in support).
• A model is growing tangled and individual changes ripple in unexpected directions.
• Team boundaries don't match code boundaries.
• The team is debating "should this be its own service?".

When NOT to use this skill

• Within-context refactoring — delegate to tactical pattern skills.
• Questions about how contexts relate to each other → route to ddd-context-mapping.
• Allocating modeling effort across the business → route to ddd-subdomain-classification.

Core content

A bounded context is conceptual, not deployment-bound. It is the scope within which a model holds together. It can be a module, a package, a microservice, or a whole system — what matters is that inside the boundary, every term has one meaning and every rule is consistent.

Signals that a boundary is needed.

• The same word means two different things in two different parts of the system.
• Two rules of the model contradict each other depending on which area of code is running.
• Two teams keep stepping on each other's changes to "the same" model.
• The UI for one user group looks nothing like the UI for another, but they hit the same domain code.

Context vs microservice. A bounded context is a model boundary; a microservice is a deployment boundary. They often coincide but don't have to. A single service can host two contexts (kept clean by module boundaries). Two services can implement the same context (rare, usually a mistake).

Naming the boundary. Give each context a name that reflects its business purpose: Sales, Billing, Shipping, Identity. Avoid technical names (Backend, Core). The name should make sense to a domain expert.

Decision heuristics

• Prefer fewer, larger contexts at the start of a project. Splitting is cheap; merging is expensive.
• Split when terms collide irreconcilably, when teams need autonomy, or when the model rules contradict.
• Do not assume one bounded context per microservice. The mapping is decided by the model, not the deployment topology.

Anti-patterns

• Declaring a bounded context per database table — performative, no model boundary actually drawn.
• Ignoring boundaries until the model breaks — by which point the cleanup is a major project.
• Treating "bounded context" as a synonym for "microservice".
• Drawing a boundary without naming the ubiquitous language inside it.

See also

• ddd-ubiquitous-language — what lives inside the boundary.
• ddd-context-mapping — how contexts relate to each other.
• ddd-subdomain-classification — which contexts deserve the most effort.

References

• Evans, Domain-Driven Design (2003), Ch. 14 (Maintaining Model Integrity).