Bounded Context
A boundary within which a domain model and its terms have one consistent meaning — the seam for splitting systems and teams.
A bounded context is a boundary — a subsystem, a service, a module — within which a particular domain model and its terminology are consistent and unambiguous. The same word can mean different things in different contexts, and each context owns its own model. It is DDD’s core structural idea and the natural seam for microservice boundaries.
Worked example: “customer” means something different to the Sales context (a lead with a pipeline stage) than to the Support context (a ticket history) — each models its own Customer rather than forcing one bloated shared model, and they integrate through explicit contracts. Gotcha: the classic failure is one giant shared model across the whole company — every team coupled to it, every change risky — so bounded contexts deliberately allow duplication and translation at the edges; getting these boundaries right is what makes microservices work, and getting them wrong is what makes a distributed monolith.