Context Mapping
A strategic DDD technique for visualizing and managing the relationships and integration patterns between bounded contexts.
Also known as: Context Map, Strategic Design Map
Category: Software Development
Tags: domain-driven-design, software-design, architecture, modeling, software-engineering
Explanation
Context Mapping is a strategic Domain-Driven Design practice for identifying, documenting, and managing the relationships between bounded contexts. A context map is a visual representation showing how different parts of a system (or organization) relate to each other—where they share models, where they diverge, and how they communicate.
**Why context mapping matters:**
In any non-trivial system, multiple bounded contexts must interact. Without explicit mapping, these interactions become implicit, leading to hidden coupling, conflicting models, and integration nightmares. Context mapping makes these relationships visible and intentional.
**Relationship patterns:**
- **Shared Kernel**: Two contexts share a small subset of the domain model. Changes require coordination between both teams. Use sparingly—it creates tight coupling
- **Customer-Supplier**: Upstream context (supplier) provides data or services to the downstream context (customer). The downstream team can negotiate requirements, but the upstream team prioritizes
- **Conformist**: The downstream context adopts the upstream context's model as-is, with no negotiation power. Common when integrating with external systems or dominant platforms
- **Anti-Corruption Layer (ACL)**: The downstream context creates a translation layer to protect its model from the upstream context's influence. Essential when integrating with legacy systems
- **Open Host Service (OHS)**: A context provides a well-defined, versioned API for multiple consumers. The protocol is designed to serve a broad range of needs
- **Published Language**: A shared language (e.g., a standard data format like JSON Schema, Protocol Buffers, or industry standards) used for inter-context communication
- **Separate Ways**: Two contexts have no integration at all—they operate independently. Sometimes the best relationship is no relationship
- **Partnership**: Two contexts evolve together with mutual dependencies. Both teams coordinate closely on changes
**Creating a context map:**
1. Identify all bounded contexts in your system
2. Map the relationships between each pair that interacts
3. Label each relationship with the appropriate pattern
4. Identify team ownership and communication patterns
5. Highlight areas of risk, friction, or misalignment
**Organizational alignment:**
Context maps often mirror organizational structures (Conway's Law). They reveal not just technical relationships but team dynamics, power asymmetries, and communication patterns.
Related Concepts
← Back to all concepts