Bounded Context
A Bounded Context is a clearly delimited area within a system in which a domain model and its terms have a single, consistent meaning. It is the central structural principle from Domain-Driven Design (DDD) and the domain foundation for microservice boundaries.
Without explicit context boundaries, models emerge that try to be everything for everyone — they are hard to maintain and lead to misunderstandings between teams.
Core Concept
A Bounded Context defines:
- Ubiquitous Language: Within the context, all terms have a precise, agreed meaning that is also visible in the code.
- Model Boundaries: Outside the context, the model may look different without causing conflicts.
- Team Responsibility: Each Bounded Context is owned by a single team (Conway's Law as an opportunity).
Context Mapping
The relationships between Bounded Contexts are visualised through Context Maps. Typical patterns:
- Shared Kernel: Two teams share a common core model that both maintain.
- Customer/Supplier: Upstream team provides the API, downstream team consumes it.
- Anti-Corruption Layer (ACL): A protective layer that shields the own model from an external one.
- Open Host Service: A published API for multiple consumers.
Focus: Deriving Microservice Boundaries from Domain Logic
Bounded Contexts prevent microservices from being split along technical layers (frontend/backend/DB) rather than along domain boundaries.
FAQ
Is a Bounded Context always the same as a microservice?
No. A Bounded Context is a domain concept; a microservice is a deployment artefact. In the early stages, a Bounded Context can live as a module within a monolith and be extracted later (Strangler Fig Pattern).
How large should a Bounded Context be?
Large enough for a single team to fully understand and own it, but no larger. Typical size: 2–5 aggregates.
Reference Guide
- Domain-Driven Design (Evans): The foundational work. dddcommunity.org
- Implementing DDD (Vernon): Practical application. O'Reilly
- Context Mapping Patterns: contextmapper.org