Review this context map. Eleven bounded contexts, and nine of the relationships between them are shared kernel: a common library of domain types that every team imports and any team may change. The teams report that releases have to be coordinated. What would you change, what would you keep, and how would you argue it?

What shared kernel actually commits you to

A shared kernel is a shared model, and a shared model means a shared release cadence for everything that touches it. It is the one relationship pattern in domain-driven design that deliberately couples teams, and it is correct only where that coupling is cheaper than translating between two models.

So the reported symptom is not a defect. Coordinated releases are the pattern working exactly as designed, and the design decision was to adopt it nine times.

What the nine relationships are telling you

If the model is genuinely shared across nine contexts, they are not bounded contexts. They are packages inside one model with a diagram drawn around them. The boundary that matters is the one you can change independently, and none of these can be.

The usual history is honest: the kernel started as three types everyone needed, and every subsequent type that two teams needed was added to it, because adding to the shared library is always the smallest immediate step.

What I would change

Convert most of the relationships to customer-supplier with a published language: the upstream context publishes events or an API with a versioned schema, and each consumer owns its own representation of the concept. Where the downstream should not be shaped by the upstream's model at all — a legacy system, or a context with a genuinely different notion of the same word — put an anti-corruption layer in and translate.

Concretely: nine contexts stop importing Order and each keeps the two or three fields of an order that its own decisions depend on.

What I would keep, even though it looks like the same mistake

One shared kernel, holding the primitives that genuinely have one meaning across the organisation: money and currency arithmetic, tenant identity, time and time zones, identifier formats. These change rarely, a bug in a duplicate implementation is worse than the coupling, and the coordination cost is near zero because nobody needs to change them.

The test is not "is this shared" but "how often does it change, and who has to be involved when it does".

How I would argue it in the review

Not with a diagram. With co-change data from version control: for the last twelve months, which contexts' files appear in the same commit. Opinion loses that argument and a co-change matrix wins it. Two contexts that change together in most commits do not have a boundary between them, whatever the map says — and two that never change together are candidates for a much weaker relationship than shared kernel.

When shared kernel is right, and when not to translate at all

When one team owns several contexts, the coordination cost is a meeting that was happening anyway and translation layers are pure ceremony. And before the boundary is known — in a monolith being decomposed, where the model is still being discovered — building anti-corruption layers early means maintaining translations for boundaries that turn out to be in the wrong place. Discover with a shared model, separate once the seam stops moving.