What is a Bounded Context
A bounded context is a concept from Domain-Driven Design (DDD) that defines a boundary within which a particular domain model applies. Inside the boundary, every term has a precise, consistent meaning. Outside the boundary, the same term might mean something different.
How it works
In an e-commerce system, "order" means different things to different teams:
- To the sales context, an order is items a customer selected, with a total and a payment method.
- To the fulfillment context, an order is a set of items to pick, pack, and ship from a warehouse.
- To the accounting context, an order is a revenue event with tax implications.
Each bounded context has its own model of "order" — its own fields, rules, and database. Communication between contexts happens through well-defined interfaces (APIs, events), not shared databases.
Why it matters
Bounded contexts are the natural boundaries for microservices. If you draw your service boundaries along bounded contexts, each service has a cohesive domain model, minimal dependencies on other services, and a clear API contract.
Bad boundaries — splitting within a bounded context or merging unrelated contexts — lead to services that are either too chatty (calling each other constantly) or too large (a monolith with a network in the middle).
Understanding bounded contexts is the prerequisite to drawing good service boundaries. The hardest part of microservices is not the technology — it is deciding where the boundaries go.
For how bounded contexts guide service design, see How Microservices Work.