factor10 Solution Designer

Field notes

Context Map

A software system beyond a certain size no longer fits in a single model. Try anyway and the language erodes: the same word means different things in different parts of the system, and teams that think they are collaborating are in fact talking past each other. One team simply is not enough to handle ongoing development and maintenance.

Alternatively, you may already know that there are different models and several ubiquitous languages "at play".

The Context Map makes it explicit: where do the boundaries run, which model and which language hold on which side, and what does the collaboration between the neighbours look like?

A Context Map describes a socio-technical system. The teams are on the map implicitly, just as much as the Bounded Contexts are (more on the teams on their own tab).

 

The main building blocks

In a Context Map you model each Bounded Context and the relationships between them. Relationship patterns (for example Customer/Supplier, Open Host Service, Anticorruption Layer, Conformist) are chosen deliberately. They describe power, coupling and model flow between Bounded Contexts and teams, rather than data flow.

Besides Bounded Contexts we can also use Data Product and Big Ball of Mud (BBoM) in the Context Map. Data Product is inspired by Data Mesh: the idea is that the same team responsible for a Bounded Context should also be responsible for what data is published, almost the opposite of centralised master data. A Data Product therefore typically belongs to a single Bounded Context and should not span or aggregate data from several. A data product that collects data from many Bounded Contexts is exactly the centralised anti-pattern Data Mesh wants to get away from.

BBoM means that a context is not "bounded", that it lacks boundaries against several other models. We make that explicit by drawing an outer boundary and labelling it with the BBoM pattern.

 

Relationship patterns (a selection)

 

Further information in the tool that does not come from DDD

The tool allows complementary information per context, for example whether someone else is responsible, whether it is multi-tenant, and which technology choices have been made.

Note also that if the initiative style is set to Delivery, the tool will warn about choices that are expected to have a negative impact on long-term changeability.

 

Further reading