When two bounded contexts have overlapping needs, DDD offers Partnership, where the two teams co-evolve in sync, and Separate Ways, where the teams deliberately avoid integrating at all, even duplicating effort. What makes Separate Ways a legitimate strategic choice rather than a failure to collaborate, and what tips a team toward Partnership instead?

## The same starting situation, two conclusions Both patterns address the same starting situation: two bounded contexts discover they have overlapping functional needs. What differs is the strategic conclusion each team draws about whether that overlap is worth building a bridge over. **Separate Ways** is the conclusion that it isn't - the two teams look at the overlap, weigh the ongoing cost of integrating against the cost of each independently reimplementing the small shared piece, and deliberately choose duplication. This is a genuine engineering trade-off, not a failure of collaboration or communication: integration is never free, since it means aligning on a shared model or contract, coordinating releases so a change on one side doesn't silently break the other, and maintaining whatever glue code connects the two contexts indefinitely. When the overlapping functionality is narrow, cheap to build, and unlikely to need deep synchronization going forward, that ongoing coordination tax can easily exceed the one-time cost of just writing the small piece twice. ## Partnership at the opposite end **Partnership** sits at the opposite end of the same decision. It's the conclusion that the overlap is deep enough, and the two teams' outcomes coupled enough, that co-investment is worth it - not through a one-directional negotiated contract the way Customer-Supplier works, but through genuinely mutual, synchronized planning where both teams treat the combined outcome as their shared responsibility. Concretely this usually means: - regular joint planning sessions covering both roadmaps together; - an agreement to coordinate releases when either side's change would affect the joint area; - and a cultural shift where an integration failure between the two contexts gets triaged as a shared incident rather than being attributed to whichever team's code technically threw the exception. Partnership requires real organizational investment to sustain - it isn't something you get for free just by declaring it - because unlike Customer-Supplier, there's no single team with final authority to break a deadlock if the two teams' priorities start to conflict. ## The decision axis The decision axis between the two patterns is best framed as **overlap depth versus coordination cost**, not as a moral judgment about which pattern is more collaborative or mature. | Kind of overlap | What the economics say | |---|---| | A **shallow, incidental overlap** - two teams that each happen to need a small 'is this user currently active' flag, say | has low strategic stakes and a cheap standalone implementation on either side, so the coordination overhead of a shared service, let alone joint planning meetings, is disproportionate to the value it would create; Separate Ways is the economically sound choice here, not a symptom of teams failing to talk to each other | | A **deep, strategically important overlap** - two teams jointly responsible for a single checkout funnel where a bug in either one directly breaks the other's core success metric | has high enough stakes and enough genuine interdependence that the cost of **Partnership's** ongoing coordination is clearly worth paying, because the alternative, each team optimizing independently with no shared visibility, would predictably produce integration failures that hurt both | ## When a Partnership has stopped paying off A concrete failure signal for a chosen Partnership is worth watching for in practice: if the joint planning meetings consistently produce no actionable coordination, or if one team's roadmap dependency on the other repeatedly causes both teams to slip deadlines without a proportional benefit showing up anywhere, the coupling cost has quietly exceeded the integration benefit that justified choosing Partnership in the first place. At that point, cutting the tie and deliberately switching to Separate Ways - accepting duplication of the small overlapping piece - is often the pragmatic fix, rather than continuing to force synchronization between two teams whose actual priorities have drifted apart. This is a real, and organizationally uncomfortable, decision to make explicitly, since undoing a Partnership usually means admitting that an earlier strategic bet didn't pay off, which is harder for people to say out loud than simply letting an underperforming arrangement limp along unexamined. ## Deliberate, not accidental It's worth distinguishing Separate Ways sharply from accidental duplication caused by two teams simply not knowing about each other's work. Separate Ways is a conscious, informed decision: both teams are aware of the overlap and explicitly agree not to integrate because the cost-benefit calculation doesn't justify it, and that decision is typically documented as part of the organization's context map so future teams don't rediscover the same overlap and assume nobody ever noticed it. Duplication that happens purely because two teams were unaware of each other isn't an application of the pattern at all - it's a coordination failure that good context-mapping practice is partly meant to surface and prevent, by making every context's boundaries and relationships visible across the organization in the first place. ## Why Partnership carries more risk It's also worth noting why Partnership carries more organizational risk than Customer-Supplier despite both involving real cooperation. - **Customer-Supplier has a built-in tiebreaker**: there's a clear power asymmetry, and ultimately one team - the supplier - owns the final decision when priorities conflict, which keeps accountability simple even under disagreement. - **Partnership has no such tiebreaker by design**, since both teams are meant to be mutually dependent peers with equal standing; if trust or communication between them breaks down, there's no built-in escalation path baked into the pattern itself; misalignment can stall both roadmaps simultaneously instead of just one, and resolving it requires an outside party, typically a shared manager or an architecture-review function, to intervene - a cost that's easy to underestimate when a Partnership is first proposed with good intentions on both sides.