Context Mapping

 

In Domain-Driven Design, a Context Map is a tool for mapping the relationships and collaboration between different Bounded Contexts. When dealing with multiple models, a map becomes crucial to represent a clean separation of responsibilities between them and their cooperation.

Eric Evans first described context maps in Domain-Driven Design: Tackling Complexity at the Heart of Software. They weren’t a heavyweight diagram constraining evolution but more of a quick sketch guiding teams in complex territory.

Greenfield vs Brownfield

An important distinction about context maps’ significance is their role in the current software development initiative. While a greenfield context map focuses on the ideal decomposition of a future system into collaborating models, a brownfield context map is more oriented towards reading the current forces constraining the collaboration between models in the present system.

This is no minor difference. Envisioning the future is a design exercise in clean modelling; reading the current status quo is a full-blown sociotechnical discovery initiative. A brownfield context map is one of the few tools to display the political forces acting on your software ecosystem.

Brownfield and Greenfield typically explore the relationships between many models surrounding our area of interest. When the map area is reduced to the collaboration between two contexts, we can talk about a local context map or translation map instead.

Drawing our brownfield map

The steps to draw a context map are very different between greenfield and brownfield. Brownfield has a more straightforward recipe:

• Detect models;
• Make boundaries explicit;
• Draw relationships between models;
• Display the relationships’ direction (upstream/downstream);
• Categorise the relationships;
• Decorate the map with annotations about the risk areas or other meaningful extra info.

The following picture will be more explicit.

Drawing relationships

A Brownfield Context Map’s most significant advantage is that it forces us to examine the collaboration between models in a way that isn’t purely technical but political.

This mostly happens by focusing on the relationships between the models

Upstream and downstream

The upstream and downstream labels show which side of the relationship has more influence over the other, constraining the available collaboration patterns.

For example, we’ll typically be downstream to external service providers, like a payment gateway, which will not consider our requests for an extra field in their API. Here, we might choose to be Conformist in our first implementation and then upgrade to a safer Anti-Corruption Layer.

In other scenarios, we might be in a dominant upstream position, offering a standard entry point to our services without much room for customization, maybe with an Open Host.

The upstream-downstream relationship captures the political relationship between the two models, not the technical one.

Emphasising Communication Bandwidth

Connectors between bounded contexts can easily convey extra information: thickness can be used to represent the available communication bandwidth between two models.

Two colocated teams could share modelling space and discuss topics in a simplified way without calling structured meetings. This proximity can be leveraged to enable highly engaging collaboration patterns such as Partnerships.

But two teams in different time zones, maybe part of other departments or—worse—companies, won’t have any chance to build a shared mindset and continuous collaboration. With little available communication bandwidth, both teams would be better off with a clear definition of the boundaries and maybe writing a little more code to compensate for the missing conversation space.

Collaboration Patterns

A Brownfield Context Map focuses on the collaboration between models. This often mirrors the collaboration between the responsible teams.
Eric Evans describes some patterns that can be used to categorise these relationships.

• A Partnership describes a collaboration where two models can evolve harmonically, like in the early days of a small company.
• A Customer/Supplier describes a more structured co-dependency, where one model needs the other more than the reversal.
• In a Conformist, the downstream model adapts to the upstream one with minimal adjustment and trading flexibility for short-term development speed.
• An Anti-Corruption Layer will protect the downstream model from variations from the upstream one. This is particularly useful when integrating with third-party components.
• An Open Host highlights the different responsibilities deriving from the upstream role of being a service provider. This will mean more work on documentation, robustness and backward compatibility.
• A Shared Kernel highlights the need for robustness and expertise to maintain a shared model in which a small change can have massive ripple effects.
• Separate Ways describes the deliberate choice to move on with minimal integration between two systems.
• Published Language refers to using a shared official language for model-to-model communication, often allowing more parties to join.
• The Big Ball of Mud describes the dynamics of a system that has lost its conceptual integrity and become more challenging to change.

Visualising the sociotechnical complexity

These patterns describe different trade-offs in the sociotechnical stack.

An Anti-Corruption Layer implies writing more code to compensate for the teams’ limited communication bandwidth. A Partnership goes in the opposite direction.

Similarly, an Open Host may be the more bureaucratic version of a Customer/Supplier, which became too demanding when more models started connecting.

Relationships between models result more from spontaneous evolution than a deliberate act of design. A Brownfield Context Map is usually a short-lived tactical tool to assess the current reality and highlight the most constraining concerns.

How to use a Brownfield Context Map

Drawing a Brownfield Context Map is a detective job: it implies asking the right questions about the surroundings of our area of interest.

Ideally, when kicking off a new project, drawing a map should take less than an hour, provided we can get the answers we need from the experts.

If getting the answers about integrations and collaborations with other teams is challenging or inconclusive, we may have already obtained crucial information about the risks associated with a project.

“We should integrate with team X, but we couldn’t get any answers from anybody about how to perform this integration.”

The perfect storm may consist of fixed deadlines and unreliable external dependencies. A Brownfield Context Map helps detect these risks very early by forcing you to ask the right questions and meet the right people before committing to a hopeless death-march project.

Mapping a greenfield space

Greenfield context mapping is a different sport. We need to detect domain hints that may point us towards independent models. This would allow us to optimise models for their specific purpose.

A single-purpose model can be sharpened and distilled to do one thing well, while trade-off models (like those built on top of a shared database schema) tend to lose flexibility over time.

Unfortunately, while purpose is the most powerful force shaping our need for a dedicated model, it doesn’t provide immediate guidance for drawing our map. We can’t ask business stakeholders to provide us with a purpose with the sharp precision needed to define model boundaries.

Finding boundaries is a software architect’s job and can’t be delegated.

Detecting Bounded Context with EventStorming

Luckily, collaborative workshops like Big Picture EventStorming can provide valuable hints about partitioning a large enterprise model, especially when organised around a business flow.

• Different stakeholders, especially those from different offices, will have different needs; hence, they will probably need separate models.
• Pivotal Events, separating distinct phases, are natural landmarks between the model(s) to the left and the model(s) to the right.
• Swimlanes usually characterise independent processes, often with a clear, specific purpose.

While none of these indicators is bulletproof, observing the emergent model and the people’s behaviour together provides incredible information about how to split a large enterprise model.

While a Big Picture EventStorming effectively detects domain signals, we must remember that Bounded Contexts are not a business concern.

Despite the invaluable contribution during the workshop, drawing the map with our business stakeholders isn’t always a good idea.

Going below the surface

Not every bounded context can be detected with signals from the business flow. Shared components may provide services or technical capabilities independently from the business flow. Often, logical layers are a better way to detect boundaries between models below the business flow surface.

Usually, we’d use a Local Context Map for that.

Local Context Maps

When working on the boundary between Bounded Contexts, concepts that may be part of both models require special attention.

This is where a Local Context Map may be helpful. It can visualise the current agreement and support the discussion when deciding which concepts belong to which model.

Refining the local Ubiquitous Language usually helps sharpen the model, keeping the involved Bounded Context sharp and clean.

Drawing the boundaries can become tricky in a layered model scenario, especially if the people trying to draw the line are also experts in the underlying layers.

In this example, we can see two models which are logically layered.

The objection “At the end of the day, it’s all text” is valid and wrong at the same time. While everything can be text, and we’ll be using some text editing capabilities, designing content for the web happens at a different level of abstraction.

Applicability

Context Maps are a versatile tool, not necessarily limited to Domain-Driven Design.

A Brownfield Context Map can be a very effective tool for capturing vital information about an initiative about to start. Moreover, the collaboration patterns can also be applied outside the software world, making the map a good tool for any transformation initiative.

Local Context Maps can be vital when working on two adjacent models simultaneously. Their ability to navigate multiple perspectives and mental models can also be helpful in complex negotiation scenarios.

 

 

---

 

Avanscoperta has deep field experience leveraging Domain-Driven Design to solve complex challenges for teams and organizations worldwide.