Documentation / Platform glossary / Bounded context
A bounded context is a boundary within which a set of terms has one consistent meaning. It comes from domain-driven design, and it exists because large organizations do not share a single definition of their core concepts — recruiting and payroll mean different things by "candidate".
The problem a bounded context solves is not technical but linguistic. Attempting one universal model for a whole enterprise produces a definition so hedged it serves nobody: a "position" means an approved headcount to finance, a job posting to recruiting, and a reporting-line slot to HR operations. Each is correct within its own work.
A bounded context accepts this. Inside the boundary, terms are defined precisely and consistently. At the boundary, an explicit translation maps between models — the recruiting notion of a candidate becomes the onboarding notion of a new hire, deliberately rather than by coincidence of field names.
What makes the boundary real is that each context owns its own data and exposes a published interface. Two contexts sharing a database table are not separate contexts; they are one model with two names for it, and a change to that table couples them permanently.
The practical value is independent evolution. Recruiting can refine its model without renegotiating definitions with payroll, because the only thing payroll depends on is the published interface, not the internal representation.
Integration projects fail more often on semantic mismatch than on protocol. Two systems that both have an "employee" record and disagree about whether contractors are included will exchange data successfully and produce wrong results — a failure that surfaces in reporting rather than in an error log.
Naming the boundary and its translation makes that disagreement explicit at design time, which is the only point where it is cheap to resolve.
QueryTek organizes Review, Tapestry, and EBM as bounded contexts with explicit interfaces, so each product can evolve its model without weakening platform-wide guarantees such as tenant isolation. Internal service structure is not published.
