Skip to main content

Context Mapping Workshop

Retrieval Prompts​

  1. State from memory the six relationship patterns between bounded contexts. Give one distinguishing property of each.
  2. Define Anticorruption Layer, Open Host Service, and Published Language in one sentence each. State who builds each.
  3. List the four required pieces of information on every edge of a context map.
  4. Give two signals that a conformist relationship should be upgraded to ACL-protected.
  5. State one reason context maps are stored as Mermaid source rather than PNG screenshots.

Compare and Distinguish​

Separate these pairs cleanly:

  • partnership vs customer-supplier -- who absorbs coordination cost, and what is the power relationship?
  • conformist vs ACL -- in both the downstream adopts the upstream's model; what is the real difference?
  • ACL vs OHS -- which side translates, and whom does the translation protect?
  • published language vs "our OpenAPI spec" -- why is one an intentional contract and the other sometimes accidental exposure?
  • shared kernel vs published language -- both are shared artifacts; what is the fundamental shape difference?

Common Mistake Check​

Identify the error in each:

  1. "We share a models/ package between the Shipping and Billing contexts so we can reuse the types. It's just a utility library."
  2. "The carrier's API is ugly, so we built an ACL on the carrier's side."
  3. "Two teams are partnering, so we do not need coordination for breaking changes."
  4. "Our OHS is stable because it's OpenAPI 3.1 and we have a schema."
  5. "We don't need a context map -- each team documents its own API."
  6. "The ACL translates JSON; it's just a JSON parser."
  7. "We use REST so we have an Open Host Service by definition."
  8. "If two contexts are in conformist, that means the downstream likes the upstream."

Mini Application -- Parcel Shipping Company, "Returns" Addition​

Parcel Shipping Co. already has:

  • Pricing (core), Shipping (supporting), Tracking (core), Billing (supporting), Customer Support (supporting)
  • Carrier Gateway (supporting) + external carriers (generic/pink)
  • Legacy ContractEngine v1 (external, conformist w/ ACL in Pricing)

Your team has been asked to add a Returns capability: customers initiate returns, a reverse-pickup is scheduled, the parcel is physically returned to a hub, an inspection decides refund/store-credit, and Billing produces the refund or credit memo.

Produce:

  1. Returns context definition. Business capability in one sentence, ubiquitous language vocabulary (6-10 terms), and core-or-supporting classification with justification.
  2. Edges. List every edge Returns shares with existing contexts. For each edge:
    • upstream / downstream
    • relationship pattern (from the six)
    • translation pattern (ACL / OHS / Published Language) if any
    • what crosses (events, API calls, shared data)
  3. Context map. Draw the updated system context map as a Mermaid diagram. Highlight the new Returns context and the edges that touch it.
  4. Fragile-edge note. Identify the one edge most at risk of drifting into a distributed monolith, and state two ways to defend it (e.g., events instead of sync, ACL, stricter versioning).
  5. Counter-example. Name one anti-alignment you considered and rejected. Explain in 2-3 sentences why you rejected it.

Constrain to 3 pages. If it spills, you are probably over-specifying edges.

Evidence Check​

This page is complete only if, given a real system, you can:

  • produce a context map in under 45 minutes with every edge labeled
  • defend each edge's pattern with an explicit heuristic and a power-dynamics argument
  • catch a shared-DB-or-shared-model anti-pattern within a single review pass
  • name and justify at least one ACL and one OHS in the system
  • diff two context maps (last quarter vs this) and summarize what changed and why

Restaurant Management Case​

Use this workflow:

Guests reserve tables. Hosts assign tables. Servers take orders. Kitchen staff prepare items. Payments close checks. Managers review sales, table turns, and staff performance.

Tasks:

  1. Extract requirements and identify domain terms that mean different things to different roles.
  2. Propose bounded contexts and classify each subdomain as core, supporting, or generic.
  3. Draw a context map with upstream/downstream direction.
  4. Identify at least two aggregates and state the invariant each protects.
  5. Mark one edge that needs an anticorruption layer and one edge that can use a published language.

Evidence check: include a short note explaining why one large Restaurant model would become ambiguous or fragile.