What is a bounded context in Domain-Driven Design?
Updated Feb 20, 2026
Short answer
A bounded context is an explicit boundary within which a domain model and its language have one consistent meaning. The same word means different things to different parts of a business — 'Customer' in Sales is a prospect with a pipeline stage, while in Billing it is an account with payment terms. Rather than forcing one universal model, DDD gives each context its own and defines how they translate at the seams.
Deep explanation
The problem bounded contexts solve is the unified model that collapses under its own weight. A single Customer class serving Sales, Billing, Support, and Shipping accumulates every field any team needed, no team fully understands it, and every change risks breaking three others.
A bounded context draws a line and says: inside here, Customer means exactly one thing.
Sales Context Billing Context Support Context ------------ --------------- --------------- Customer Customer Customer - leadSource - billingAddress - openTickets - pipelineStage - paymentTerms - satisfactionScore - assignedRep - creditLimit - supportTierThree classes, three meanings, one real-world person. Each is complete and comprehensible within its own context.
Contexts must talk, and the relationship is a design decision. DDD names the common patterns:
- Shared kernel — two contexts share a small agreed model. Tight coupling; requires close coordination.
- Customer/supplier — the downstream context's needs influence the upstream one's roadmap.
- Conformist — downstream simply accepts the upstream model as given, no negotiation.
- Anticorruption layer — downstream translates the upstream model into its own, protecting its design from a foreign or legacy one. This is the pattern that most often earns its keep.
The context map is the artefact recording which contexts exist and how they relate. Teams that skip it end up with implicit, undocumented coupling.
Relationship to microservices. A bounded context is a strong candidate for a service boundary, since it is already a unit of consistent meaning and language. But they are not the same thing — a context is a modelling concept, a service is a deployment concept, and one context may be deployed as several services or as part of a modular monolith.
Real-world example
An e-commerce platform where "Product" fractures naturally:
Catalogue Context: Product { name, description, images, categories, seoSlug }Inventory Context: Product { sku, warehouseLocations, quantityOnHand, reorderPoint }Pricing Context: Product { sku, basePrice, taxClass, discountRules }Catalogue does not care about reorder points; Inventory does not care about SEO slugs. They correlate by SKU, and an anticorruption layer translates when Catalogue must display a price.
The failure mode is the "god" Product table with 80 columns, where adding a pricing field requires regression-testing the catalogue search — the exact coupling bounded contexts exist to prevent.
Common mistakes
- - Trying to build one canonical model for the whole business, which produces a class nobody owns and everybody fears changing.
- - Treating a bounded context as merely a namespace or module, rather than a boundary of *meaning* with its own ubiquitous language.
- - Sharing a database across contexts, which recouples them at the storage layer no matter how clean the code boundaries look.
- - Equating one bounded context with exactly one microservice
- they are related but answer different questions.
- - Skipping the anticorruption layer when integrating a legacy system, letting its model leak in and corrupt the new design.
- - Drawing boundaries along technical lines — controllers, services, repositories — instead of along business capabilities.
Follow-up questions
- What is the ubiquitous language and how does it relate to bounded contexts?
- What is an anticorruption layer?
- How do you decide where a context boundary belongs?
- Is a bounded context the same as a microservice?