Bounded Context
A bounded context is the scope within which a single domain model stays consistent and unambiguous. Inside it, one Ubiquitous Language holds; outside it, the same word may mean something else entirely. Where two contexts meet, you map the relationship rather than sharing a model.
This is the most durable pattern in DDD: almost pure intent with no mechanism to age, so it survived object-orientation, ORMs, distribution, and remote teams untouched. The field converged onto Evans’s exact term rather than coining its own: Newman credits him, as do Skelton and Pais, whose Team Topologies names the bounded context as its preferred fracture plane for splitting systems and teams.
One live debate: a bounded context is not the same as a microservice. Every microservice is a bounded context, but a bounded context is the widest valid boundary, not the narrowest, so treating the two as one-to-one is a default some authors accept (Vernon) and others reject (Khononov).
Signal: cross the boundary and at least one term changes meaning; within it, nobody has to qualify which sense they mean. Part of Domain-Driven Design.
Sources
- Eric Evans, Domain-Driven Design Reference (2015): the bounded context as the scope within which a model and its ubiquitous language stay consistent, the term the field converged on.
- Sam Newman, Building Microservices: credits Evans’s term, and where the bounded-context-to-service question actually gets argued.
- Matthew Skelton and Manuel Pais, Team Topologies (2019): names the bounded context as its preferred fracture plane for splitting systems and teams.
- Vaughn Vernon, Domain-Driven Design Distilled (2016): accepts the context-per-service default that Vlad Khononov, Learning Domain-Driven Design (2021), rejects.