Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
3 to work through
-
intermediate
Review this context map. Eleven bounded contexts, and nine of the relationships between them are shared kernel: a common library of domain types that every team imports and any team may change. The teams report that releases have to be coordinated. What would you change, what would you keep, and how would you argue it?
2 min answer -
advanced
A payments platform has one Payment entity used by checkout, settlement, refunds, reconciliation and reporting, and it has grown to eighty fields. What is the problem and what is the fix?
2 min answer -
advanced
Two teams disagree about whether "reservation" and "booking" are one concept or two. What evidence settles it?
2 min answer
3 terms in this topic
Bounded Context
A boundary within which a model and its vocabulary are internally consistent, and outside which the same words may legitimately mean something different.
practiceContext Map
A diagram of the bounded contexts in a system and the relationship type between each pair, making integration expectations and power dynamics explicit.
patternShared Kernel
A deliberately shared subset of the domain model between two contexts, which removes translation cost by accepting a shared release cadence - the one…
1 artifact you would hand over
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.