A Domain Context Map is a structured method to capture bounded contexts, their responsibilities, shared kernels, and integration patterns. It visualizes relationships, ownership and communication paths to reduce ambiguity and guide architectural and organizational decisions. It is used in discovery workshops and architectural planning.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Executable approach: can be applied and produces an outcome.
What organizes, connects, or makes decisions possible.
A Domain Context Map organizes domain boundaries, responsibilities, and coupling so architecture and organizational decisions rest on clear ownership.
The method belongs to the strategic side of Domain-driven Design, described by Eric Evans in 2003. It addresses the problem of managing large software systems without forcing everything into one model. Context mapping therefore makes bounded contexts, responsibilities, shared parts, and common integration patterns explicit so translation, coupling, and technical as well as organizational boundaries can be decided deliberately.
Think of the map as a city plan for the domain: each bounded context is a district with its own language and responsibility. Boundaries show where the local model applies and where translation is needed. Links show whether teams collaborate closely, stay deliberately decoupled, or exchange through a mediator. The result is a readable overview of domain boundaries, interfaces, and dependency direction.
A domain area with its own model and language.
Internal and external conditions shape a context's structures, processes, and governance.
Patterns such as Conformist, Published Language, or Open Host Service describe how contexts are connected.
A small shared part of the model requires close coordination and limits shared change.
A translation layer protects the local model from foreign semantics and unsuitable dependencies.
The map is useful for domain slicing, integration planning, team alignment, and modernization efforts, especially in workshops and architectural decisions. Its value depends on strong facilitation and a shared understanding of language. Too coarse a map hides important differences; too fine a map becomes hard to read and costly to maintain.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.