Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 4 of 7 Intermediate 25 min

Drawing the Seams — Context Mapping for Business Owners

Prerequisites: When Everyone Means Something Different — Why Disambiguation Matters, The Shared Language Toolkit — DDD Core Vocabulary for Business Owners, Reading the Room — How Event Storming Surfaces What Actually Happens

What You'll Learn

  • What a context map shows and why it is a business tool just as much as a technical one
  • How to read and interpret upstream/downstream relationships between bounded contexts in plain terms
  • How to look at a context map and identify which team owns what, where handoffs occur, and where friction is likely
  • Why context maps are living artifacts — never finished — and how to use them as a prop in ongoing cross-team conversations
  • How context mapping relates to but differs from event storming: event storming discovers; context mapping documents the relationships

Why This Matters

This framework resolves the ambiguity of who owns what by making bounded context boundaries and their relationships visible and shared.

Think back to the Meridian Insurance story from Module 01. Engineering built one "approval" workflow — and it was wrong for both Underwriting and Claims because nobody had drawn the map first. Both groups used the word "approval," both groups assumed they meant the same thing, and nobody had written down who owned what. The cost was three months of rework and a delayed product launch. Context mapping is the discipline that prevents exactly that failure. It gives you a shared picture of where one team's responsibility ends and another's begins, and it makes the handoffs between them explicit.

You do not need to be an engineer to read or draw a context map. In fact, if business owners are absent from context mapping sessions, the map ends up being technically accurate but organizationally wrong — because engineers rarely know who owns the customer record or who makes the final call on a claim payout. That knowledge lives with you.

Core Concept

A context map (a visual sketch showing the relationships and handoffs between bounded contexts; who owns what, who depends on whom, where translation occurs) is the answer to a deceptively simple question: "Who owns what, and how do these parts talk to each other?"

To draw one, you start from the bounded contexts (a clearly defined boundary within which a specific team uses consistent terminology and owns a coherent set of capabilities; the seams between bounded contexts are where translation happens) you identified in earlier work — perhaps from a DDD vocabulary session or from the clusters of related events that emerged during event storming. Each bounded context becomes a labeled region on the map, often drawn as a box with a name and the owning team written inside. The boxes alone are not the point; the arrows between them are.

Upstream and downstream

Every relationship between two bounded contexts has a direction. The upstream context (the direction of influence — the upstream context defines the terms; the downstream context adapts) sets the terms and the model. The downstream context receives that model and adapts to it. This is not just a technical observation; it is a business accountability statement. The upstream team defines what "customer" means. If you are downstream, you either accept that definition or you pay the translation cost.

Consider who owns the customer record in your organization. Sales might claim they own it because they created it. Underwriting might claim they own it because they approved the policy. In context mapping terms, one of those contexts is upstream — and settling that question ends the argument. The map makes the decision visible rather than leaving it to be relitigated in every project meeting.

Three integration patterns in plain language

When two bounded contexts need to share information, the nature of that relationship matters. There are three patterns worth knowing at a conceptual level:

Conformist — The downstream context simply accepts whatever the upstream context provides. There is no translation layer. The downstream team has chosen (or been forced) to model things the way the upstream team already models them. This is the lowest-friction option, but it also means downstream has no independent language of its own for those concepts.

Anti-corruption layer — The downstream context creates a deliberate translation zone between itself and the upstream. Inside that zone, incoming upstream terms are converted into the downstream team's own language. This costs more to build and maintain, but it protects the downstream team's ability to think and work in its own terms. It is worth the cost when the upstream model does not reflect the downstream team's reality well enough.

Shared kernel — Two contexts agree to share a small, carefully managed piece of vocabulary or model. Both teams must approve any changes to that shared piece. This creates tight coupling, so it should be used sparingly and only for concepts that genuinely belong to both contexts equally.

You do not need to choose these patterns in advance. The context map reveals where each pattern already exists, often implicitly, and makes it a conscious choice rather than an accident.

A business accountability tool

The deeper value of a context map is not technical. It answers the questions that cause the most damage when they go unanswered:

  • Who owns the definition of "customer"?
  • When a policy is issued, who needs to know, and whose version of the event is authoritative?
  • Who makes the call on "approval" — and are we even talking about the same approval?

Without a context map, these questions are answered differently by different people in different meetings. With a context map, you can point at a boundary and ask: "Whose responsibility is this handoff?" The map turns an organizational dispute into a concrete, drawable thing.

Context maps are living artifacts

A context map is not a diagram you produce once and file away. It is a working sketch — ideally on a wall or in a shared space where any team member can update it. As your business changes, as teams reorganize, as new systems emerge, the map changes too. Its value comes from the conversations it provokes, not from its accuracy on a particular day.

Concrete Example

After the Meridian Insurance event storming session (described in Module 03), the team steps back and looks at the clusters of domain events on the wall. Three natural groupings emerge.

The first cluster contains events like "Quote Requested," "Application Submitted," and "Sales Opportunity Opened." These are owned by Sales. The second cluster contains "Risk Assessed," "Coverage Decision Made," "Policy Issued," and "Premium Set." These belong to Underwriting — the Policy Context. The third cluster contains "Claim Filed," "Incident Assessed," "Settlement Approved," and "Payout Disbursed." These belong to Claims — the Claims Context.

The team draws three labeled boxes on a whiteboard. Then they draw the arrows.

Sales is upstream of the Policy Context. Sales originates the customer relationship — it gathers the application and passes it to Underwriting. Underwriting does not decide whether to go looking for customers; it processes what Sales sends.

The Policy Context is upstream of the Claims Context. A claim can only be filed against a policy that already exists. Claims depends on Underwriting's version of the policy record — including what is covered, at what level, and under what terms.

Now look at the hotspot from Module 03: the "approval" disagreement. The context map resolves it structurally. There are not one but two approvals:

  • Coverage approval — the moment Underwriting decides whether a risk is acceptable. This lives in the Policy Context, owned by Underwriting.
  • Payout approval — the moment Claims decides how much a settlement is worth. This lives in the Claims Context, owned by Claims.

These are different decisions, owned by different contexts, with different criteria and different consequences. The context map makes that visible. Engineering's mistake in Module 01 — building one approval workflow — now has a clear cause: nobody had drawn this map. There was no shared picture of the seam between Policy Context and Claims Context, so Engineering collapsed two things into one.

The Meridian context map also reveals an integration pattern. Claims is a Conformist with respect to the Policy Context: when a claim is filed, Claims uses Underwriting's policy record as-is. Claims does not maintain its own version of what is covered; it reads it from the Policy Context. This is the correct choice — Claims has no business defining coverage terms — but making it explicit means the team can discuss it, challenge it, and change it if circumstances evolve.

Analogy

Think of context mapping as urban zoning and transit planning.

A city is made up of neighborhoods. Each neighborhood has its own character, its own rules, and its own internal logic — a residential zone has different regulations than an industrial zone. You would not put a steel mill next to a school; the activities are incompatible, and the language the residents use to describe their day-to-day is completely different. That is what a bounded context is: a zone with its own consistent rules and vocabulary.

Now think about the roads and transit lines between neighborhoods. A commuter train connects the financial district to the suburbs. Cargo trucks move goods from the port to the warehouse district. These connections have direction: cargo does not flow from the supermarket back to the port; it flows the other way. That direction — and who controls the infrastructure — is the upstream/downstream relationship.

The context map is the city planner's map: it shows the zones, labels who governs each one, and draws the transit routes between them. When a city grows and a new neighborhood is added, the planner does not throw the map away; they update it. And when there is a dispute over whose jurisdiction covers the waterfront, planners pull out the map and point.

Going Deeper

The DDD literature includes several more named integration patterns beyond the three covered here (Conformist, Anti-corruption layer, and Shared kernel). Two others are worth being aware of without necessarily acting on immediately.

An Open Host Service is when the upstream context publishes a well-documented, stable interface that multiple downstream contexts can consume. Think of it as publishing an official API with a formal specification. The upstream team has made a commitment to stability; downstream teams can rely on it.

Separate ways is the pattern where two bounded contexts simply have no relationship. They operate independently and do not integrate. This sounds obvious, but explicitly documenting it prevents engineering teams from inventing integrations that do not need to exist.

One more subtlety worth understanding: the relationship between team topology and context topology. Conway's Law — a long-standing observation in software development — states that organizations design systems that mirror their own communication structures. Context mapping makes this visible. If two teams own different parts of what should be one cohesive context, the friction you feel in every meeting is reflected in integration friction in the system. The map can reveal whether a re-organization of team responsibilities might reduce both organizational and technical friction at once. That is a business conversation, not a technical one.

Common Misconceptions

Misconception 1: A context map is an architecture diagram.

This is the most common confusion. Architecture diagrams tend to be formal, detailed, and produced for a specific audience at a specific moment. A context map is a working sketch — drawn on a whiteboard, scribbled on a sticky note, captured informally in a shared document. It is intentionally approximate. If you are spending hours perfecting boxes and arrows in a diagramming tool, you are optimizing for the wrong thing. The value of a context map is that it provokes the right conversations, not that it is precise. The day you mistake it for a formal deliverable is the day it stops being useful.

Misconception 2: One team equals one bounded context.

It is tempting to assume a clean correspondence — one team, one bounded context, one system. Reality is messier. A large team might own multiple contexts. A context that began in one system might have been split across two systems for historical reasons. A legacy platform might contain three distinct contexts that never talk to each other, all maintained by one team. Context mapping is valuable precisely because it exposes these misalignments. If a team owns a context that has grown too large, or if a context has been split across teams without anyone noticing, the map makes those problems visible.

Misconception 3: Context mapping is a job for engineers or architects, not business owners.

This is the most damaging misconception of the three. Engineers can draw the technical dependencies between systems accurately, but they typically cannot answer the business accountability questions that give those dependencies their meaning: Who owns the authoritative customer record? When there is a dispute about what "approval" means, which team has the final say? What happens to a claim when the policy record changes? These are not engineering questions. They are ownership and accountability questions, and business owners are the only people who can answer them. A context map drawn without business owners is technically plausible but organizationally fictional.

Check Your Understanding

  1. In the Meridian example, Sales is upstream of the Policy Context (Underwriting). What does that mean in practice for how Engineering should build the system?

    Reveal answer It means the Policy Context should accept the customer and application data that Sales produces, in the form Sales produces it, rather than requiring Sales to restructure its data to match Underwriting's internal model. The upstream context (Sales) defines the initial record; the downstream context (Policy Context) adapts to receive it. Engineering should build the integration so that the Policy Context handles any necessary translation, rather than forcing Sales to change how it captures customer information.

  2. Why does naming both approvals — "coverage approval" and "payout approval" — solve the problem that caused the original Meridian failure, rather than just relabeling things?

    Reveal answer The original failure happened because everyone used the word "approval" as if it referred to one thing, so Engineering built one workflow. Naming the two approvals separately does more than give them different labels — it establishes that they belong to different bounded contexts, with different owners, different criteria, and different consequences. Once the map shows that coverage approval lives in the Policy Context (owned by Underwriting) and payout approval lives in the Claims Context (owned by Claims), Engineering must build two separate workflows. The names are a symptom; the structural ownership is the fix.

  3. The Claims Context is described as a Conformist with respect to the Policy Context. What would the Meridian team need to decide before switching to an Anti-corruption layer instead?

    Reveal answer They would need to determine whether Claims has a genuinely different mental model of a policy — one that is obscured or distorted by having to use Underwriting's version directly. If Claims adjusters think about coverage in ways that do not map cleanly onto how Underwriting records it, a translation layer would let Claims speak its own language internally. The cost is the translation layer itself — building and maintaining it. The question to ask is: is the translation cost worth the benefit of letting Claims model policies in its own terms? If Claims is small, or if its model closely matches Underwriting's anyway, the Conformist pattern is simpler.

  4. A colleague says, "Let's update the context map once we finish building the new system — that way it will be accurate." What is wrong with this approach?

    Reveal answer Context maps are valuable during design and construction, not just after it. If you wait until the system is built, the map becomes a description of what was done, rather than a tool for making decisions about what to do. The conversations that context maps provoke — who owns this? how should this handoff work? is this the right integration pattern? — need to happen before and during the build, not after. An after-the-fact map also misses the disagreements that were resolved along the way; it only shows the outcome, not the reasoning.

  5. How does context mapping complement event storming, and in what order would you typically do them?

    Reveal answer Event storming discovers the business process — it surfaces the domain events, the commands, the actors, and the hotspots. Context mapping documents the relationships between the bounded contexts that the event storming session reveals. You would typically run event storming first, then use the clusters of related events that emerge as the raw material for drawing bounded context boundaries and the arrows between them. Event storming is discovery; context mapping is the structural documentation of what was discovered.

Key Takeaways

  • A context map is a visual sketch of bounded contexts and the relationships between them — who owns what, who depends on whom, and where translation occurs.
  • Upstream/downstream direction is a business decision as much as a technical one: the upstream context sets the terms; the downstream context adapts.
  • Three integration patterns to recognize: Conformist (downstream accepts upstream as-is), Anti-corruption layer (downstream translates to protect its own model), and Shared kernel (both contexts share a carefully managed piece of vocabulary).
  • Context maps resolve ownership ambiguity — like the Meridian "approval" confusion — by making explicit that two contexts can use the same word to mean two different things, owned by two different teams.
  • Context maps are living artifacts; their value comes from the conversations they provoke, not from being a polished finished diagram.

References