Integrating Bounded Contexts

Continuing through Learning Domain-Driven Design by Vlad Khononov. The teaser I left at the end of chapter 3 was: once bounded contexts exist, how do they talk to each other without collapsing back into one giant model? Chapter 4 answers it, and the answer turns out to be less about protocols than about teams.

The Patterns Are About Power, Not Protocols

What stood out first is that the integration patterns aren’t sorted by technology. They’re sorted by the relationship between the teams on either side of the wall. Khononov groups them in three buckets (cooperation, customer–supplier, and separate ways), and which bucket you land in depends on whether the teams can talk to each other, whether either of them can dictate to the other, and whether they’re willing to coordinate at all.

That feels right. The contract between two bounded contexts always looks like an API question. What actually decides whether it works is upstream of the API: who picks the schema, who pays when it changes, and whether the two teams are in the same building or barely on speaking terms.

Cooperation: When Two Teams Actually Talk

The cooperation bucket has two patterns. The looser is partnership: two teams coordinate ad hoc, one notifies the other when the contract changes, and the other adapts. Nobody dictates. It needs cheap, frequent communication and continuous integration, because the feedback loop has to stay short for the ad-hocness to work.

Shared kernel is the tighter option. Two contexts share a piece of model: same source code, immediately reflected on both sides. This is the carefully bounded exception to chapter 3’s rule that no two teams own a bounded context. The justification is a cost calculus. Shared kernel only pays when duplicating the model would cost more than coordinating changes to it. Because volatility drives coordination cost up, the pattern is most defensible exactly where it sounds most dangerous: in the core subdomains, which change most often. Anywhere else, a shared kernel is a smell.

Customer–Supplier: When Power Is Lopsided

Most real integrations aren’t peer-to-peer. One side has the upper hand, usually because it can succeed without the other. The chapter names three patterns for this quadrant, and they mostly differ in who swallows the cost.

The cheapest is conformism. The downstream accepts the upstream’s model as given. This is the right answer surprisingly often, especially for generic or supporting subdomains where the upstream’s model is good enough and an indirection layer would dwarf the benefit.

An anticorruption layer is more expensive on the downstream’s side. It still depends on the upstream, but translates at the boundary so the upstream’s model can’t leak in. The criteria for when this is worth paying for are concrete: the downstream is a core subdomain; the upstream is a mess (legacy systems being the canonical case); or the upstream’s contract churns often enough that you want a single point of impact.

Open-host service flips the cost the other way. The upstream protects its consumers by publishing an integration-oriented language that’s separate from its internal model. The internal model can evolve freely; the published language stays stable. This is the pattern that lets a popular service scale to many consumers without dragging them along on every refactor.

The Context Map Is an Org Diagnostic

The chapter closes with the context map: plot every pair of bounded contexts and label which integration pattern joins them. On the surface it’s a system diagram. In practice it’s an organizational X-ray.

If every downstream of a particular upstream team is running an anticorruption layer, the upstream’s model is bad and everyone else is paying for it. If separate ways keeps clustering around the same team, that team is hard to work with. The context map turns Conway’s Law into something you can measure rather than a vibe.

That’s what I want to keep from this chapter. The patterns themselves aren’t novel; most of them are folk wisdom about API design under a tighter name. What’s new is the framing. Pick the pattern based on which two humans, speaking which two languages, with which power dynamic, are standing on either side of the wall. Then plot the result and stare at the picture for a while.

Onward to chapter 5, where the book closes out the strategic half and starts on the tactical patterns.

Part of the Learning Domain-Driven Design series.