Bounded Context (DDD)
A bounded context is a domain-driven design boundary within which a particular domain model is internally consistent and unambiguous. It is the primary unit for defining microservice scope.
Bounded context = different departments in a hospital. 'Patient' means a billing record to finance and a medical chart to the ER — same word, totally different meaning depending on which floor you're on.
Within a bounded context, the ubiquitous language is precise — 'Order' in the payments context means something different from 'Order' in the fulfillment context. The contexts communicate via explicit contracts (events or API calls) using translation layers (anti-corruption layers or open host services). Each context owns its own data store — this is the defining constraint that prevents the data coupling of a distributed monolith. Context maps document the relationships: conformist, customer/supplier, shared kernel, anti-corruption layer.
The hardest part of bounded context design is deciding where to draw the lines. Heuristics: (1) cohesion of data — if two services always query each other's data, they likely belong in the same context; (2) team ownership — a context should be owned by at most one team to avoid the coordination overhead of multi-team ownership; (3) change frequency — parts of the domain that change independently should be separate contexts. A common mistake is creating bounded contexts that are too small (nanoservices that must always call each other synchronously to make any decision) — the dependency graph is the litmus test: if a service cannot perform its primary operation without synchronous calls to five others, the boundary is wrong.
I use event storming workshops with domain experts to identify bounded contexts. Key signals for a boundary: different teams own different parts, the domain language differs (same word means different things), or the data change rates are very different. Once I have candidate boundaries, I draw a context map to make the coupling explicit — if I see more than 2–3 conformist relationships, the boundaries probably need to be reconsidered.
Mapping bounded contexts 1:1 to database tables or REST resources rather than to business capabilities. Technical boundaries rarely align with domain boundaries.