Bounded context
A bounded context is the boundary within which a particular domain model — its terms, rules, and invariants — is consistent and authoritative. The same business concept (e.g., 'Order') may exist in multiple bounded contexts (Sales Order, Fulfillment Order, Billing Order) with different attributes and lifecycles. The boundary is explicit; translation between contexts happens at the boundary.
Bounded contexts are the strategic-DDD answer to the question 'why does our 200-engineer codebase feel like a tangle?' — usually because too many concepts cross boundaries without explicit translation. The diagnostic move is a context map: name every bounded context, draw the relationships (shared kernel, customer-supplier, anti-corruption layer, conformist), and identify where ambiguity lives. Bounded contexts often map well to team boundaries (Conway's Law) and to service boundaries in a microservices architecture; they don't have to, but the alignment is healthy when it happens.
Related terms
- Domain-driven design
Domain-driven design (DDD) is a software-design approach, formalised by Eric Evans in 2003, that places the business domain at the centre of model design.
- Conway's Law
Conway's Law, formulated by Melvin Conway in a 1968 paper, states that any system's design mirrors the communication structure of the organisation that built it.
- Microservices
Microservices is an architectural style where a single application is composed of many small, independently-deployable services, each owning its own data and communicating over the network.