In DDD's Customer-Supplier context relationship, the downstream team is called the 'customer.' What power does that give them over the upstream 'supplier' team, and how does this differ from a Conformist relationship?

## Same topology, different power dynamic Both Customer-Supplier and Conformist describe the same underlying topology: one context is upstream, feeding a model or data to a downstream context that depends on it. What distinguishes the two patterns is entirely about the power dynamic and communication channel between the two teams, not the technical shape of the integration. | Pattern | The downstream team's standing | |---|---| | **Customer-Supplier** | the downstream team has genuine standing as a paying customer of the upstream team's output, even if no money changes hands - they get a seat in planning, their feature requests are prioritized alongside the upstream team's own roadmap items, and there's typically a concrete governance mechanism that makes the arrangement durable rather than just a friendly verbal promise | | **Conformist** | that standing simply doesn't exist: the downstream team has no meaningful way to influence what upstream builds or when, so rather than fighting an uphill battle to negotiate a custom contract or building expensive translation machinery that upstream might invalidate at any time, the downstream team accepts upstream's model wholesale and adapts its own code to match it directly | ## What makes the agreement enforceable The mechanism that operationalizes Customer-Supplier in practice is usually a combination of: 1. **a regular planning cadence** - joint sprint planning, a shared backlog, or scheduled roadmap-alignment meetings; 2. **automated consumer-driven contract tests**, a technique where the downstream team writes tests expressing exactly what they need from the upstream API, and the upstream team runs those tests as part of their own continuous-integration pipeline before shipping any change. This turns an informal promise ('we won't break you') into a mechanically enforced one: if an upstream change would violate a downstream expectation, the upstream team's own build fails before the change ever ships, rather than the break being discovered by the downstream team in production. Conformist has no equivalent machinery, because there's no negotiated contract to enforce in the first place - downstream simply builds against whatever upstream currently does, and absorbs the impact of any change upstream makes on its own schedule. ## Why they are two patterns, not one The reason DDD names these as two separate patterns rather than treating Customer-Supplier as simply 'good Conformist' is that the choice between them is often not really a choice at all - it's a reflection of organizational reality. - **Where Conformist is the honest label.** A downstream team integrating with a large public cloud vendor's billing API has essentially no path to Customer-Supplier standing: the vendor won't reprioritize their roadmap for one customer among millions, so Conformist is the honest, appropriate label, and fighting that reality by pretending you have negotiating power wastes energy. - **Where Customer-Supplier standing is real.** Conversely, two internal teams within the same organization, especially where the downstream team's success is important to the company, usually can and should establish real Customer-Supplier standing, because the organizational structure supports it and the alternative - either forcing Conformist onto an internal team that could otherwise get real influence, or building an unnecessary Anti-Corruption Layer against a cooperative partner - wastes coordination effort that a negotiated relationship would have avoided. ## Relationship drift A common failure mode is relationship drift: a pairing that's nominally labeled Customer-Supplier on an architecture diagram, with joint planning meetings still notionally scheduled, but where the upstream team consistently deprioritizes the downstream team's requests sprint after sprint regardless of what was agreed. At that point the relationship has silently degraded into Conformist in practice, even though everyone still calls it Customer-Supplier - the label without enforced influence is meaningless, and continuing to plan as if real negotiating power exists leads to repeated missed expectations and downstream teams building fragile workarounds around promises that never actually materialize. The corrective action is either escalating for a genuine prioritization commitment, or explicitly re-labeling the relationship as Conformist and building the appropriate defenses, such as an Anti-Corruption Layer, since the downstream team can no longer safely assume upstream will accommodate its needs. ## Defined per context pair It's also worth noting the relationship type is defined per context pair, not as a global property of a team. A platform team providing a core pricing service might sit in weekly Customer-Supplier planning with one important internal consumer while a lower-priority internal team, or an external partner with no negotiating leverage, simply has to conform to whatever the platform team ships, with no seat at the table at all. The same upstream context can be in genuinely different relationships with different downstream contexts simultaneously, and correctly identifying which relationship actually exists - rather than which one is aspirational - is what lets a downstream team make sound architectural decisions about how much to invest in defensive translation versus how much to rely on negotiated stability.