Two teams, Checkout and Fulfillment, need to integrate, and Checkout's team is much larger and moves faster than Fulfillment's. What context-mapping relationship patterns describe the possible power dynamics between two integrating bounded contexts' teams, and how do you choose which one to apply?

## What context mapping names Once two bounded contexts need to integrate, DDD's **context-mapping** vocabulary names several distinct relationship patterns describing how the two owning teams relate to each other - and the choice between them is driven less by pure technical elegance than by **organizational reality**: relative priority, trust, communication bandwidth, and negotiating power between the teams involved. ## The relationship patterns - **Customer-Supplier** describes a relationship where the downstream ('customer') team has enough organizational standing that the upstream ('supplier') team commits, as part of its own planning process, to considering the downstream team's needs - the supplier might not do everything the customer asks, but the customer has a recognized seat at the table, typically formalized through shared planning meetings, an agreed backlog, or a service-level expectation. This works when the downstream team's needs are legitimate and important enough that the upstream team is incentivized (organizationally, not just technically) to accommodate them. - **Conformist** is the relationship where the downstream team has little or no influence over the upstream team's model, and rather than fight for customization, simply adopts the upstream model exactly as given, translating nothing. This sounds like a worse outcome, but it's frequently the pragmatically correct choice: if the upstream model is reasonably well-designed, changes infrequently, and the political cost of negotiating custom accommodation from a much larger or more powerful upstream team (think: a small product team consuming a big internal platform team's API) exceeds the benefit of a perfectly tailored model, conforming is simply cheaper than fighting. The risk is that Conformist can also happen by default, not by choice - a team lacking leverage may be forced to conform even when the upstream model genuinely doesn't fit their needs, silently absorbing friction that never gets addressed. - **Partnership** describes two teams whose success is mutually interdependent enough that they co-design and co-evolve their shared interface collaboratively, with joint planning and shared commitment to keeping the integration healthy - neither team is simply 'upstream' or 'downstream'; both have skin in the game and coordinate as equals. This works well for two teams delivering a single business capability together but choosing to organize as separate teams/contexts for other reasons (team size, deployment independence), and requires real, ongoing communication bandwidth between the teams to sustain. - **Shared Kernel** is different in kind from the others: rather than two teams integrating across a boundary via an interface, they explicitly agree to share a subset of the model's actual code (types, and sometimes the underlying schema) that both must jointly maintain, with any change requiring mutual agreement. This avoids duplicating a small, genuinely stable, foundational concept both contexts need identically - a shared Money value object with currency-handling logic, for instance - but it comes at the cost of coupling: any change to the shared kernel now requires coordinating across every team depending on it, which does not scale gracefully past a small number of tightly collaborating teams. ## Why the choice is organizational, not technical Choosing among these isn't primarily a technical decision - it's an organizational one, and **Conway's Law** is the reason why. Conway's Law observes that a system's structure tends to mirror the communication structure of the organization that builds it; the corollary for context mapping is that the relationship pattern you can realistically sustain is constrained by how the teams actually communicate day to day, not by which pattern looks best on an architecture diagram. You can decide on paper that Checkout and Fulfillment should have a Partnership, but if the two teams sit in different divisions, report up through different leaders, and never actually talk except through a ticket queue, the real relationship will drift toward an unhealthy, ad hoc version of Conformist or Customer-Supplier regardless of the label, and pretending otherwise just means the documented architecture stops matching reality. ## The production signal of a mismatched choice In production, the failure signal for a mismatched pattern choice is friction that keeps recurring in the same shape: 1. a downstream team that keeps requesting changes an upstream team keeps deprioritizing - a Customer-Supplier relationship that was never actually granted, functioning as an unacknowledged, adversarial Conformist relationship; 2. or a Shared Kernel that has grown to include three or more teams and now requires a standing coordination meeting just to land routine changes, which is the concrete symptom of a pattern that was appropriate at a smaller scale outgrowing its usefulness.