When a bounded context needs to expose its model to many other consumer contexts at once, not just one partner team, what integration pattern lets it do so without each consumer coupling directly to its internals, and how does it work?

## When one bespoke translation stops scaling When exactly one other context needs to integrate with yours, a bespoke translation - an **Anti-Corruption Layer** built and owned by the consumer - works fine. The calculus changes once many independent contexts need to consume your model at once: - building N bespoke integrations against your ever-changing internals means every internal refactor risks breaking N unrelated teams simultaneously; - every consumer duplicates similar translation logic. **Open Host Service (OHS)** paired with a **Published Language** is DDD's named pattern for this specific shape of problem: a provider context deliberately designs and exposes a stable, well-documented public interface for many consumers, decoupled from its own internal implementation, instead of leaving each consumer to reverse-engineer or directly depend on internal details. ## The two things the provider builds Mechanically, this means the provider builds two things that are explicitly kept separate. 1. **First, an internal domain model** that the provider team is free to refactor, rename, and restructure at will, because it's a private implementation detail. 2. **Second, a public-facing surface** - REST endpoints, a GraphQL schema, an event stream with a defined message schema, or a query API - that is treated like a product with its own lifecycle: documented, versioned, and covered by an explicit or implicit backward-compatibility promise. That public surface's shape and vocabulary is the '**published language**' - a shared, agreed vocabulary and schema that every consumer can rely on without having to understand the provider's internal domain model at all. A Pricing context, for example, might internally represent price calculation with a complex rules-engine model full of implementation-specific types, while its OHS exposes a simple, stable `GetCurrentPrice(sku, region) -> PriceResult` interface and a `PriceChanged` event with a fixed, versioned schema - the consumer contexts (Sales, Reporting, Promotions, Billing, a mobile backend) all code against that published surface, never against Pricing's internal rules-engine types. ## Not just 'having an API' Why does this exist as a distinct pattern from simply 'having an API'? Because plenty of APIs are **accidental** - convenience endpoints built for one specific caller, or thin wrappers directly over internal database rows, that happen to get reused by other teams later without any deliberate compatibility contract. OHS names the deliberate version of this: the provider team consciously decides 'we are a platform for many consumers now,' and invests specifically in decoupling the public contract from internal representation and in maintaining that contract's stability as a first-class responsibility, the same way a public library maintainer treats a public API differently from a private helper function. ## The trade-off, and who pays it The trade-off is real and lands mostly on the **provider**. Maintaining a published language means the provider can no longer freely reshape the public surface without a deprecation and migration process - a field can't just be renamed; it typically needs to be added alongside the old one, with the old one deprecated on a schedule, because breaking it breaks every consumer simultaneously rather than one. This is a genuine cost in engineering time and caution that a purely internal model doesn't carry. In exchange, the provider absorbs the translation complexity **once, at the source**, instead of leaving several separate teams to each build and separately maintain their own brittle translation against a moving internal target - which is both more total engineering work across the organization and a worse failure mode, since an internal schema change under the bespoke-integration approach can silently break several unrelated consumer teams at once with no single point of coordination. ## When it is the right call, and when it is overkill OHS is the right call specifically when the integration topology is **many-to-one** - a genuine platform or utility context serving several independent consumers - and becomes overkill for a single, tightly-coupled partner relationship, where one of these is cheaper than standing up a fully productized public contract: - a one-off Anti-Corruption Layer built by that one consumer; - a **Customer-Supplier** relationship where the provider simply commits to considering the one consumer's needs directly. In production, teams that skip OHS when they should have adopted it typically discover the gap only after the fact: an internal refactor lands, and several unrelated teams' bespoke integrations break simultaneously, at which point retrofitting a stable published contract onto an already-widely-consumed internal model is considerably more painful than designing one deliberately from the start.