notes_on_context_maps.md

A Context Map Should Answer:

• Where is the technical debt?
• Where are the areas of technical risk?
• What knowledge gaps do you have?

---

Spectrum of cooperation

• Published language
• Open host
• Customer/supplier
• Conformist
• Anti-curruption layer

ppp_ddd_highlights.md

Highlights from "Patterns, Principles, and Practices of Domain-Driven Design"

Context Mapping

Introduction

Teams that don’t have a good understanding of the different contexts within a system, and their relationships to one another, run the risk of compromising the models at play when integrating bounded contexts. Lines between models can become blurred resulting in a Big Ball of Mud if teams don’t explicitly map and understand relationships between contexts.

The technical details of contexts within systems are not the only force that can hamper the success of a project. Organizational relationships between the teams that are responsible for contexts can also have a big impact on the outcome of a project. Often, teams that manage other contexts are not motivated by the same forces, or they have different priorities. For projects to succeed, teams usually need to manage changes in these situations at a political rather than technical level.

Other nontechnical challenges can appear during development. These are issues that arise from the areas of the problem domain that sit between bounded contexts that have not been explicitly de ned. These important business processes can often be devoid of responsibility from development teams and business ownership, but paradoxically are immensely important to business work ows and processes.

The Technical Reality

It is extremely important that context maps re ect reality, showing the code in the present state rather than an ideal future state. Context maps need not show the detail of a model; instead, they must demonstrate the integration points and the ow of data between bounded contexts. Like the code model and analysis model, the context map should change only when code changes so it does not give a false impression of the landscape. The map should show the stark reality; only then will it be useful.

The Organizational Reality

It is vital to understand who is responsible for each context that is required to change and how this change will take place. If the process of coordination and prioritization of changes is not understood, it can be a massive stumbling block and sti e development as teams wait on others to act on requests for change. Showing the direction of team relationships is one of the strengths a context map has over traditional UML or architectural diagrams.

Mapping a Relevant Reality

When creating a context map, try to focus on your immediate problem area; you need to understand the landscape that will affect the success of your project and not the entire enterprise. A focus only on the contexts that you will be directly integrating with helps you get going with context mapping and prevents you from losing focus.

Shared Kernel

The pattern is of particular use if you have two bounded contexts in the same subdomain that share a subset of domain logic.

An Upstream/Downstream Relationship

The relationships between bounded contexts can be de ned in terms of a direction; one end will be upstream and the other downstream. If you are the downstream end of the relationship you are dependent on data or behavior of the upstream end. The upstream end will in uence the downstream context.

Retaining Integrity

All development teams in the organization need to understand the context map. Teams don’t need to understand the inner workings of each bounded context; instead, they need to be aware of those other contexts—the application programming interface (API) they expose, the relationships they have, and, most importantly, the conceptual models they are responsible for. With this information, teams can prevent blurring the lines of responsibility and ensure that all contexts retain their integrity.

Retaining integrity is important to keep your codebase focused on a single model. This enables the code to become supple because any change affects only a single bounded context and doesn’t have a rippling effect across multiple areas of your domain. It’s this suppleness that enables you to alter code and to adapt quickly and con dently when the business needs a change to process or logic.

The Basis for a Plan of Attack

A context map highlights areas of confusion and mess, and, more importantly, where the core domain is. Teams can use this information to identify areas they need to clear up rst to improve the success of a project:

• Areas that are too far gone and where the effort to improve is far greater than the payback can be isolated and left.
• Areas of no strategic advantage or that are of low complexity need not incur the cost of creating a ubiquitous language or follow the model‐driven development methodology.
• Areas that are core to the success of the project or are complex are candidates for the tactical side of Domain‐Driven Design, and should be kept isolated from poorly designed bounded contexts to retain integrity.

Understanding Ownership and Responsibility

Accountability and responsibility are other nontechnical areas that can affect a project.

Defining team ownership and management for subsystems that you need to integrate with is essential for ensuring changes are made on time and in line with what you expect.

Context mapping is about investigation and clari cation; you may not be able to draw a clear context map straight away, but the process of clarifying responsibility, explicitly de ning blurred lines, and understanding communication ow while mapping contexts is as important as the nished artifact.

Revealing Areas of Confusion in Business Work Flow

The business processes that happen between and take advantage of bounded contexts are often left in no‐man’s‐land without clear responsibility and clarity regarding their boundaries and integration methods.

A context map, focusing on the nontechnical aspects of the relationships, can reveal broken business process ow and communication between systems and business capabilities that have degraded over time.

Encourages Good Communication

When the diagram also indicates that you are the upstream team, you understand that your responsibility is usually to lead decision making, and accordingly, you may often need to initiate communication.

Helps On‐Board New Starters

Having a concise, yet informative, context map that the whole team regularly views and keeps up to date is a fantastic way to ensure all team members understand the bigger picture—or at least have an idea of which parts of the system they don’t know enough about.

If a domain expert approaches you with a problem that you’re unfamiliar with, you can turn to the context map for suggestions about who it would be best to talk to.