Introduction to Context Mapping

This is a really awesome intro into Context Mapping, if your getting started or even if you need a refresher.

My notes & takeaways (25)

These are things we are looking to get our teams to achieve. The Bounded Context helps achieve that.
The ddd-crew github repo has a lot of tools, like the DDD starter Modelling Process to get you started
A Bounded Context is a boundary for a model expressed in a consistent (ubiquitous) language tailored around a specific purpose.

A Bounded Context is a boundary. It has it’s own language within the boundary. There is a purpose to it, too - Reusability is not key concern. Models are specific.

It can also be seen as team first boundary (Team Topologies space).

The bounded context does not show the dynamics between contexts (nor between teams).

On Conway's Law

Conway’s law is not about the org structure on the chart - it’s about the dynamics in that org chart. It’s about the communication structure.
Context Maps are a bit of a hidden gem in the DDD space, since most look at the Tactical patterns immediaely.
We’re used to communicating between services using REST API synchronous call or consuming events. But we can see other types of communication. For instance, the propagation of models based on the messages passed back and forth is an effect. There is always some type of coupling.

Context Maps address a few concerns:

  • Dependencies between components and teams
    • Mutually Dependent
    • Free
    • Upstream / Downstream (reflects on power dynamics: Upstream team normally has power over downstream teams)

The 9 patterns

Open-host Service (OHS)

One API for several consumers. API provider (Open host provider) is generally Upstream. Rare cases where the Open-host service (power control) is downstream is in regulator related scenarios.

Anti-Corruption Layer (ACL)

ACL is basically a model-to-model transformation. Downstream team uses ACL to transform external model into it’s own.

Be aware that is costs time and money.

Conformist (CF)

Conformist just takes and consumes upstream model

On Coupling

ACL is not about decoupling (because you can’t) - it’s about loose-coupling. Conformist is deep coupling
There are heuristics towards choosing Conformist. It does reduce effort when choosen.

Shared Kernel (SK)

Shared Kernel physically shares an artifact. JARs, DLLs, DBs. It’s considered an Anti-Pattern.

If you want to autonomy, you want to avoid Shared Kernel.

There’s heuristics for it too. It can be a trade-off. Avoid it, for sure, if teams are in a competitive nature - it becomes toxic (politics).

Partnership (PNR)

Needed for shared kernels - establishes cooperative relationships.

Customer - Supplier (CUST - SUP)

Upstream - downstream relationship. Customer (downstream team) has some influence granted on the Supplier (upstream team) planning.

It’s organizational - doesn’t show up in code.

Seperate Ways (SW)

It’s a Free-style relationship. Very expensive.

Published Language (PL)

Standardized language in most cases. Creates independence between teams. Often combined with OHS.

We’d expect that an OHS have a well documented interface and a well documented / defined language.

Big Ball of Mud (BBoM)

it’s a warning sign; You want ACLs against these.
Describes communication patterns too
Affects domain types, too