🤖▶️ Check out the Design Patterns Overview course by Steve @ardalis Smith!Check it out »Hide


Context Mapping

Context Mapping

Context Mapping enables seeing how bounded contexts integrate with each other. Context maps show the relationships between bounded contexts and may also indicate relations of teams maintaining those bounded contexts.

Team Relationships

There are three common team relationships:

  • Partnership
  • Upstream/Downstream
  • Nonrelated


In a partnership, the maintainers of both bounded contexts are aligned with a common set of goals. These teams must collaborate and communicate in order to be successful.

Bounded Context A
Bounded Context B


The Upstream/Downstream relationship means that the effects of the Upstream team are felt by the Downstream team. However, changes made by the Downstream team do not significantly impact the Upstream.

Think of a Publisher/Subscriber (PubSub) relationship. When a publisher publishes messages, the subscribers all retrieve their messages. If a subscriber changes how they handle a message, the other subscribers and the publisher aren't impacted by those changes. However, if the publisher publishes the message in a different format, all subscribers are impacted by that change.

Publisher (upstream)
Subscriber 1 (downstream)
Subscriber 2 (downstream)
Subscriber 3 (downstream)


When the teams maintaining two bounded contexts are independent, they may be seen as nonrelated. Another term that you may see is "Free". Just as the bounded contexts aren't linked, the teams do not need to be linked either.

Independent Bounded Contexts
Bounded Context A
Bounded Context B
Bounded Context C

Context Map Patterns

There are different patterns of maps that can happen between bounded contexts. Note that some of these are good, while others are anti-patterns.

The common context map patterns are:

  • Anti-Corruption Layer
  • Big Ball of Mud
  • Conformist
  • Customer-Supplier
  • Open Host Service
  • Partnership
  • Published Language
  • Separate Ways
  • Shared Kernel

Anti-Corruption Layer

Team Relationship: Upstream/Downstream

The anti-corruption layer serves as a translation layer between upstream and downstream teams. This layer is commonly built with Facades and Adapters.

Big Ball of Mud

Team Relationship: Chaos - a mix of all of them

In a Big Ball of Mud, the code is as gross as the name implies. In DDD, the big ball of mud may have aggregates muddied together with no clear understanding of bounded contexts. The code is tightly-coupled. Debugging turns into a game of "whack-a-mole" in terms of trying to track bugs throughout the code. This is a nightmare.


Team Relationship: Upstream/Downstream

The Conformist pattern can be seen as a dysfunctional upstream/downstream relationship. The upstream has no motivation to support the downstream. The downstream may struggle with establishing a ubiquitous language with the upstream and be dependent on the upstream to establish it. When the struggles are bad and the support isn't there, the downstream has to conform to whatever the upstream has as-is and hope that it gets it right.


Team Relationship: Upstream/Downstream

The Customer-Supplier pattern where the Supplier is the upstream, and the Customer is the downstream. They work together to establish the needs of the Customer. The Customer indicates priority of needs, and the Supplier takes that into consideration when planning its delivery. Ultimately, the Customer is relying on the Supplier to deliver a solution that fulfills their needs.

Open Host Service

Team Relationship: Upstream/Downstream

The Open Host Service gives access to a system via services. It may be implemented through protocols or interfaces.

APIs that are well-documented and pleasing to use are Open Host Services. These are hosted by upstream teams and consumed by downstream teams.


Team Relationship: Partnership

When a failure in delivering one bounded context can result in a failure of another bounded context, those two contexts are a partnership. The teams that maintain those bounded contexts must work together to ensure success of both contexts and avoid total failure due to the failure of at least one.

Published Language

Team Relationship: Upstream/Downstream

With the Published Language pattern, there is a common language used for information exchange. This pattern goes well with the Open Host Service. Examples of Published Language include XML, JSON, iCal, vCard, Avro, and Protobuf.

Separate Ways

Team Relationship: Nonrelated

In Separate Ways, there is no significant relationship between two bounded contexts. These two bounded contexts can exist without having an established relationship between them.

Shared Kernel

Team Relationship: Partnership

The Shared Kernel is the intersection between bounded contexts. When there is a shared component between bounded contexts, both teams maintaining those bounded contexts must establish a ubiquitous language and apply it to their shared


Edit this page on GitHub

On this page

Sponsored by NimblePros