A bounded context is a boundary within which a specific domain model is defined and consistent. Inside that boundary, every term has a precise, unambiguous meaning, and the model faithfully represents one perspective of the business domain. Different bounded contexts may use the same terms with different meanings - and that is by design.

How It Works

Consider an e-commerce system. The “Product” in the catalog context has a name, description, images, and categories. The “Product” in the warehouse context has a weight, dimensions, shelf location, and stock count. The “Product” in the pricing context has a base price, discount rules, and tax category. These are three different models of the same real-world thing, each optimized for its context.

Bounded contexts communicate through well-defined interfaces: APIs, events, or shared contracts. Translation between models happens at the boundary (an anti-corruption layer), not inside the context.

Why It Matters

Bounded contexts solve the problem of trying to create a single unified model that serves the entire organization. A universal model inevitably becomes bloated, inconsistent, and owned by no one. Bounded contexts allow each team to maintain a focused, accurate model of their part of the business.

For microservice architecture, bounded contexts provide the natural decomposition boundary. Each microservice corresponds to a bounded context with its own database, API, and domain model. This alignment ensures that services are cohesive (everything in the service relates to one domain concept) and loosely coupled (services communicate through explicit interfaces, not shared databases).

Practical Guidance

Identify bounded contexts through domain expert conversations, not technical analysis. Look for places where language changes: when different teams use the same word differently, or different words for the same concept, you have found a boundary. Draw a context map showing the relationships between contexts (upstream/downstream, shared kernel, customer/supplier). Use this map to guide team organization, API design, and data ownership. Do not split contexts too finely - each context needs enough scope to be a coherent, useful unit of work.

Sources

  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. Chapters 14-17: Distillation and Strategic Design. (Original bounded context definition; context maps and integration patterns between contexts.)
  • Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley. Chapter 2: Domains, Subdomains, and Bounded Contexts. (Practical bounded context identification and context mapping; upstream/downstream relationships.)
  • Fowler, M. (2014). Bounded context. martinfowler.com. (Concise canonical reference widely cited in microservices decomposition discussions.)