Bounded Context
A boundary within which a model and its vocabulary are internally consistent, and outside which the same words may legitimately mean something different.
The insight that makes domain-driven design practical: the search for one enterprise-wide definition of "customer" is not merely difficult, it is misguided. To sales a customer is a prospect with a pipeline stage; to billing an account with payment terms; to support a person with a ticket history; to logistics a delivery address. These are genuinely different concepts wearing the same word.
A bounded context makes that explicit. Within it, the model is consistent and the vocabulary is unambiguous. Across contexts, translation happens deliberately at the boundary rather than by pretending the models are the same.
This is the most reliable basis for service boundaries, because it aligns the technical boundary with a linguistic and organisational one. Services drawn on bounded contexts tend to have stable interfaces and low coupling; services drawn on technical layers or on nouns from a database schema tend not to.
The practical detection technique is to listen for the same word being used differently, or for a model that requires conditional logic depending on which part of the business is asking — both signal a boundary that has been erased rather than crossed.
The context map is the companion artifact: which contexts exist, and what relationship each pair has — shared kernel, customer-supplier, conformist, anti-corruption layer. That map predicts where integration pain will occur more accurately than any component diagram.