In Domain-Driven Design, a Context Map is a visualization tool used to show the relationships between different bounded contexts within a domain. It is essentially a map that displays how the various contexts in a domain interact with each other, including their boundaries, their dependencies, and their communication patterns.

Bounded contexts are important in DDD because they help to identify and manage the complexity of large domains by breaking them down into smaller, more manageable parts. By understanding the relationships between different contexts, development teams can collaborate more effectively and ensure that each context is designed in a way that is consistent with the overall goals of the domain. Context Maps also help to highlight areas of potential conflict or overlap between contexts, which can be addressed early on to avoid issues down the line.

A context map typically includes the following constituents:

1. Context: A specific domain or subdomain that has a bounded context with explicit boundaries and a well-defined ubiquitous language.
2. Bounded Contexts: A boundary that defines a specific domain or subdomain in which the terms and concepts have a specific meaning.
3. Relationships: The relationships between bounded contexts. At a broad level, relationships are are of two types: symmetric or asymmetric. In a symmetric relationship, both sides have a more or less equal say in how the relationship evolves. In an asymmetric relationship, one of the sides acts as a clear power center
4. Teams: Teams responsible for the development and maintenance of a bounded context or subdomain.
5. Strategic Goals: The strategic goals that each bounded context aims to achieve.

A context map provides a high-level view of the domain and how different bounded contexts are related to each other, helping stakeholders to identify the system’s architecture, dependencies, and risks.

There are several relationship types that can be depicted on a context map, including:

1. Partnership: A relationship between two bounded contexts where they collaborate as equal partners to achieve a common goal.
2. Shared Kernel: A relationship where two bounded contexts share a portion of the domain model or a data source.
3. Customer-Supplier: A relationship between two bounded contexts where one context provides functionality or data to another context, which consumes it.
4. Conformist: A relationship where one context is aligned with another context and conforms to its rules, standards, or policies.
5. Anticorruption Layer: A relationship where a layer of translation is used to isolate one context from another context with an incompatible model or technology.
6. Open Host Service: A relationship where a bounded context provides a public API that can be used by external clients or other bounded contexts.
7. Published Language: A relationship where two bounded contexts agree on a shared language or vocabulary to communicate with each other.
8. Separate Ways: A relationship where two bounded contexts are completely independent and have no interaction with each other.

Example

Here is simplified context map for a fictitious XYZ bank. This visual depicts the various bounded contexts, their relationships. In the case of asymmetric relationships, it also indicates which side is upstream versus downstream. Looking at this visual should give onlookers a clear idea of the overall big picture of the software real estate at XYZ Bank.

Comparison to the C4 model

The C4 model offers an alternate way to describe the architecture of your solution. Specifically, the system context diagram is very similar in nature to the context map in that they are both used to visualize the architecture of a software system. However, there are some key differences between the two approaches.

The DDD context map is a high-level diagram that shows the different bounded contexts within a system. Each bounded context is a self-contained domain that has its own language, models, and services. The DDD context map is a useful tool for understanding the overall architecture of a system and how the different bounded contexts interact.

The C4 model’s system context diagram is a more detailed diagram that shows the different containers and components within a system. Each container is a grouping of components that share a common infrastructure. The C4 model’s system context diagram is a useful tool for understanding the internal architecture of a system and how the different containers and components interact.

Here is a table that summarizes the key differences between the two approaches:

DDD context map	C4 model’s system context diagram
Show different bounded contexts	Show different containers and components
High-level diagram	More detailed diagram
Useful for understanding overall architecture	Useful for understanding internal architecture