A catalogue context is read by nine other contexts. Six query its tables directly and three call endpoints that return its internal entity shape. The team now wants to rename and split two internal entities and finds it cannot. They propose publishing one supported model at the boundary. What does that buy what does it cost and when does the bill arrive?

What is gained

Today the catalogue's internal model is its integration contract, so a rename is a nine-team change and the team's own refactoring is blocked by consumers it does not control. Publishing a model at the boundary - the relationship Evans' 2003 work calls an open-host service with a published language - separates the two jobs:

• Translation happens once, inside catalogue, instead of nine times in consumers. That is the quantified benefit: one mapping to maintain rather than nine independently drifting ones.
• The internal model becomes changeable again. Split an entity, rename a column, change the storage - as long as the published shape still answers the same questions, no consumer knows.
• The contract becomes testable and versionable rather than implicit. A field nobody consumes can be removed, because consumption is now visible at the boundary instead of hidden in six teams' SQL.

What is paid

• A second model, permanently. Two shapes, a mapping between them, and tests for the mapping. Every new concept in the catalogue is now a decision - does it belong in the published model or not.
• Versioning and deprecation as a process. Once the shape is published, changing it needs two versions live and a window for consumers to move. For nine internal consumers that window is realistically a quarter or two, not weeks.
• Performance work at the boundary. Consumers who used to join against catalogue tables now ask questions through an interface, and the ones who were doing wide joins will need either a denormalised read model or a batch export. This is the cost people forget, and it is the one that produces the "the API is too slow, can we have database access" conversation six months later.
• The migration itself, which is the real work: six direct readers have to be moved off the tables, and the access has to actually be revoked. A compatibility view over the published shape buys time; a deadline makes it finish.

When the bill arrives

At the first breaking change to the published model - the moment the team discovers that the published shape has become as hard to change as the internal one was, because now nine consumers depend on it with a stated promise. The difference is that the promise is explicit and versioned, so the change is a planned deprecation rather than a surprise outage.

The second bill arrives if the published model is allowed to become the organisation's canonical model, accepted by every context rather than published by one for its consumers. Then nobody can change it at all. The guardrail is ownership: catalogue owns it, consumers do not negotiate its contents, and a consumer that needs a different shape translates on its own side.

The decision rule

Publish when there are three or more consumers and the internal model needs to change. With one or two consumers, cheaper relationships win: conform to one of them, or agree a small shared kernel and accept the shared release cadence. With nine consumers and a blocked refactor, the published model is the cheapest option available.

When this is the wrong answer

When the consumers are all your own team's services and deploy together. The published model then buys isolation from yourself, and the translation layer is ceremony - rename the entity and fix the callers in the same commit.

When the real problem is that catalogue owns too much. Nine consumers may be a sign that the context is three contexts, in which case publishing one model freezes the wrong boundary in a contract and makes the split harder. Check the consumers' queries first: if each group of three reads a disjoint set of fields, publish nothing yet and split the context instead.