Bounded Context Identification
Bounded context identification finds the seams where a single domain model must split because the same word means different things to different teams, preventing a monolithic model that serves no.
Definition
Bounded context identification is the process of discovering the boundaries at which a ubiquitous language changes meaning — where "product" means a catalog item to sales and a shippable unit to logistics — and splitting the model along those seams so each context has a consistent language and team ownership.
Context and scope
Applied in domain-driven design, large-scale refactoring, and any organization where a shared model forces every team to negotiate every term.
Common misconceptions
- Bounded contexts map to microservices — they are a modeling concept; a microservice is one deployment option, but a bounded context can span services or live in a monolith
- One bounded context per team is the rule — the boundary follows the language, not the org chart; a team may own several contexts and a context may cross teams
Anti-patterns
- Splitting by entity type rather than by semantic boundary, producing contexts that share a language and couple anyway
- Drawing the boundary at the database table, so the contexts share storage and cannot evolve independently
Related concepts
Authoritative source
What it is
Bounded context identification is the process of discovering the boundaries at which a ubiquitous language changes meaning — where “product” means a catalog item to sales and a shippable unit to logistics — and splitting the model along those seams so each context has a consistent language and team ownership. Applied in domain-driven design, large-scale refactoring, and any organization where a shared model forces every team to negotiate every term. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.