Bounded Context
A boundary within which a particular domain model is defined and consistent.
A bounded context is a boundary around a part of your domain where a specific model applies and a specific language is used consistently. Inside that boundary, every term has one clear meaning. Outside it, the same word might mean something different.
Consider "user" in a billing system versus an authentication system. In billing, a user has invoices, payment methods, and a billing address. In auth, a user has credentials, sessions, and roles. Trying to force both into a single User model creates a mess. Bounded contexts let each part of the system define "user" in the way that makes sense for its purpose.
Bounded contexts also help with team organization. Each context can be owned by a different team, deployed independently, and evolved at its own pace. Whether you run them in a monolith or as microservices is a deployment detail, not an architectural one.
Getting the boundaries right matters. The Aggregate pattern and Event Storming are practical tools for discovering where one context ends and another begins.
References
- Software Dark Ages — Describes Bounded Context as a Strategic DDD pattern that helps split big models into smaller, logical pieces with clear transaction boundaries.
- When using Microservices or Modular Monolith in Go can be just a detail? — Shows how bounded contexts map to Go packages in both monolith and microservice deployments, with imports between contexts going through interfaces.
- The Distributed Monolith Trap (And How to Escape It) — Discusses how bounded contexts and shared kernel let multiple teams own separate models of the same concept, like the user entity, without coupling.
- DDD: A Toolbox, Not a Religion — Covers bounded contexts as part of DDD terminology and explains how separate contexts help teams figure out domain boundaries.