Context Map in Domain Driven Design
Sep 17, 2021
Context Map is an important part of Domain Driven Design. It demonstrates the integration points and the flow of data between Bounded Contexts. Bounded Contexts are not independent. A system cannot exist without the interaction between its components. In this article, I will describe the Context Map.
A Context Map defines a relationship between two Bounded Contexts. The relationship is influenced by the present state of the domain, technical and organizational concerns.
The relationship between Bounded Contexts causes the relationship between teams.
The touchpoints between Bounded Contexts are called Contracts. The Contracts can be categorized into eight types:
- Partnership
- Shared Kernel
- Customer-Supplier
- Conformist
- Anticorruption Layer
- Open Host Service
- Published Language
- Separate Ways
Partnership
This kind of integration is mostly based on connections between teams. They cooperate together to have a clear contract that defines the connection between the Bounded Contexts.
To achieve the Partnership goals, the communication and synchronization between teams are crucially important.
Shared Kernel
This kind of integration is based on sharing part of the Domain Model which defines the contract between two Bounded Context.
To achieve the Shared Kernel goals, the commitment and synchronization between teams is crucially important.
Customer-Supplier
This kind of integration is based on providing services from one Bounded Context (Supplier or Upstream) to another Bounded Context (Customer or Downstream).
The Customer always depends on the services that the Supplier provides and the Supplier promises to provide all needs of the Customer.
Conformist
This kind of integration is like the Customer-Supplier, but the Supplier does not promise to provide Customer’s needs.
This kind of relationship mostly happens when the Supplier (Upstream context) is not able to collaborate with the Customer (Downstream context) and the Customer needs to conform to the Supplier. For instance, The Supplier is a third-party component.
Anticorruption Layer
This kind of integration is based on the fact that two different Bounded Contexts may have different Ubiquitous Language and/or different modeling techniques. This differentiation in the context of integration may lead to adaptation that causes corruption in the Bounded Context. To prevent corruption, Anticorruption Layer can be used.
Anticorruption layer contains translation logic, there is no business logic.
Open Host Service
This kind of integration provides clearly defined, explicit contracts for multiple consumers.
When a Bounded Context has a relationship with multiple Bounded Context; it can provide an Open Host Service that prevents other Bounded Contexts from having their own Anticorruption Layer.
Published Language
This kind of integration provides a language from Upstream to describe and formalize the details of integration in which Downstream can use it. Published Language often used alongside the Open Host Service.
Published Language is like a document of the service(s) that Upstream provides for Downstream; this kind of document makes a lower disruption from Downstream to Upstream.
Published Language can be defined with XML Schema or JSON Schema.
Separate Ways
This kind of integration can be used when the cost of other integrations is not affordable; technical and/or political complexities could be reasons to choose this method. In this way the integration could be designed in a Separate Ways like integration via user interface.
Summary
Context map is a concept that represents the system’s Bounded Contexts and integrations between them. There are several methods of integration that also represent the relationship between teams that are responsible for Bounded Contexts. It is important to choose a proper method of integration in the Domain Model.