Stackbook Logo
architecture-descriptionestablished · low operational burden

Bounded Context

Also known as: ddd-bounded-context, model-boundary

Intent

Define an explicit boundary within which a domain model and its language are consistent and unambiguous.

Problem

In large systems the same word, such as Customer or Product, means different things to different teams. A single shared model becomes bloated, contradictory, and impossible to change safely.

Forces

  • •Different business capabilities need different views of the same concept
  • •One enterprise-wide model collapses under conflicting needs
  • •Teams need autonomy to evolve their models
  • •Contexts must still integrate

Solution

Overview

A bounded context is the part of a system where a particular model applies. In a retail company, Sales sees a Customer as a buyer with a cart; Support sees a Customer as a ticket owner; Billing sees an account with invoices. Each model is right inside its own context.

How it works

Discover contexts through event storming and conversations with domain experts. Listen for language shifts: when a term changes meaning, you have likely crossed a boundary. Then give each context its own model, repository, and ideally its own schema.

[Sales]           [Billing]          [Support]
 Customer          Account            Requester
 Cart              Invoice            Ticket
    \_____ events / APIs / translation _____/

Contexts exchange data by identifiers and published messages. For example, Sales publishes OrderPlaced with a customer ID and amount; Billing creates its own Invoice from it and never reads Sales tables.

Pitfalls

  • Equating a bounded context with a microservice; a context can live in a modular monolith.
  • Sharing entity classes through a common library, which silently recreates one model.
  • Drawing boundaries around nouns or database tables rather than around language and responsibility.
  • Never documenting relationships; use a context map to record them.
  • Splitting too early, before invariants and language are understood.

Key takeaways

  • A model is only valid within its boundary.
  • Boundaries follow language and team ownership.
  • Integrate through contracts, not shared storage.
  • Record relationships in a context map.

✓ When to Use

  • •Large domains with multiple teams and subdomains
  • •When terminology conflicts appear between departments
  • •Before decomposing a monolith into services

✗ When Not to Use

  • •Small applications with one team and one vocabulary
  • •Early exploration where the domain is unclear
  • •When boundaries would be purely technical rather than linguistic

Pros

  • +Smaller, coherent models
  • +Team autonomy and clear ownership
  • +Natural seams for service extraction

Cons

  • −Duplication of concepts across contexts
  • −Integration work between contexts
  • −Wrong boundaries are expensive to fix

Cost Profile

Infrastructure

None directly — may map to separate services

Operational

Low to medium — depends on deployment split

Cognitive

Medium — requires domain discovery

Failure Modes

  • Boundaries drawn along technical layers instead of language

  • Shared database that couples contexts despite separate code

  • Too many tiny contexts creating integration overload

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      requirements constraintseconomics evolution