Skip to content
Software Architecture Guide

Bounded Context

Explanation

Section titled “Explanation”

A model is a simplified picture of a business area. The larger the area, the harder it is to build one unified model for all of it. Domain-Driven Design (see the article Domain-Driven Design) responds by dividing a complex domain into several bounded contexts and mapping the relationships between them.

A bounded context marks the boundary where one specific domain model applies. Each context holds the model of a subdomain, which is one part of the wider business domain.

Language depends on context. Each bounded context can have its own ubiquitous language (see Ubiquitous Language). The same word can therefore mean different things in different contexts. “Account” is a typical example.

One model per context. Sharing a single model across subsystems adds complexity and slows change. It is better to build separate models of the same real-world thing, one per context. Each model keeps only the attributes that matter there.

Ownership. Each bounded context owns its model and its database. Team ownership should line up with the contexts. Conway’s law can be used on purpose: analyze the domain to set boundaries, then assign teams to match. If one team owns several unrelated contexts, or one context needs coordination across many teams, revisit the boundaries or the team structure.

Context maps. A context map shows how bounded contexts relate. It highlights integration points and clarifies responsibilities. It can include external systems. Fowler considers drawing one usually worthwhile. See Context Map.

Microservices. A microservice is like a bounded context that is also a distributed service. The bounded context idea itself does not require distribution. A context can be a logical boundary inside a monolith, while a microservice is a separate process. See Microservices Architecture.

Example

Section titled “Example”

An online shop has a Sales context and a Shipping context. In Sales, a “customer” has a payment history and discount level. In Shipping, the same person is a “recipient” with an address and delivery window. Each context has its own model and its own database. A context map shows where the two connect.

Trade-offs

Section titled “Trade-offs”

Separate models mean the same real-world thing is described more than once. The facts above favor this over one shared model, which adds complexity and slows evolution. Splitting also needs care. Boundaries and team structure must be kept in step, and a mismatch is a signal to revisit them.

Two bounded contexts model the same person differently and connect at an integration point.

Diagram source 
flowchart LR
  subgraph Sales
    C1[Customer: payment history, discount level]
  end
  subgraph Shipping
    C2[Recipient: address, delivery window]
  end
  Sales -- integration point --> Shipping

Checks

Section titled “Checks”
  • The document lists its bounded contexts and states which subdomain model each one holds.
  • A context map shows the relationships and integration points between contexts, including external systems.
  • Each bounded context owns its model and its database.
  • Each context has a clear owning team, and no team owns several unrelated contexts.
  • Terms that mean different things in different contexts are defined per context.
Section titled “Related”

Sources

Section titled “Sources”