How do Open Host Service and Published Language work together when a bounded context needs to serve many downstream consumers, and why is publishing an Open Host Service without a genuine Published Language often not enough?

## The scaling problem it solves **Open Host Service** addresses a scaling problem that shows up once an upstream context has more than a couple of downstream consumers. A negotiated Customer-Supplier relationship works well for one or two consuming teams, but negotiating and maintaining a separate bespoke integration contract with every one of, say, eight consuming teams becomes an enormous ongoing cost for the upstream team: - eight sets of custom field mappings; - eight sets of contract tests; - eight separate conversations every time something needs to change. OHS solves this by having the upstream context design and expose a single general-purpose interface - a REST API, an event stream, a GraphQL schema - built around the upstream domain's own natural shape rather than any one consumer's specific needs, and every consumer integrates against that same one interface. The upstream team now maintains one contract instead of N of them, and new consumers can onboard without requiring a new negotiation at all. ## What makes the service trustworthy **Published Language** is the piece that makes an OHS actually trustworthy rather than just convenient. It's the explicit, stable, well-documented schema or vocabulary the OHS speaks - concrete field names, data types, enum values, and their precise business meaning, ideally versioned so consumers know when and how it's allowed to change. Without it, an OHS is still just one API endpoint, but its meaning is implicit: consumers infer what a field means by reading source code, asking in a chat channel, or guessing from example payloads, and different consumers frequently arrive at different, subtly incorrect interpretations of the same field. A genuinely Published Language typically lives as a standalone artifact - a schema registry entry, a published OpenAPI or AsyncAPI specification, sometimes an externally recognized industry-standard vocabulary such as HL7 in healthcare - that exists independently of any one running service instance and can be inspected, versioned, and diffed on its own. ## Two separable mechanisms The two patterns are conceptually separable even though they're usually deployed as a pair. - **An OHS's mechanism** is about the delivery channel: how many consumers a single well-documented integration point can serve, and how the upstream team's maintenance cost stops scaling linearly with consumer count. - **A Published Language's mechanism** is about meaning: whether the data crossing that channel has a precise, agreed, and durable definition. You can, in principle, have a Published Language without a single OHS behind it - several genuinely different services all choosing to speak the same standardized vocabulary independently, each maintained by different teams - and you can build an OHS whose 'documentation' is really just a swagger page auto-generated from code with no real governance over what changes are allowed, which technically satisfies the letter of OHS while missing the trust benefit a real Published Language provides. ## The trade-off The trade-off is investment versus flexibility. Designing a genuinely general-purpose OHS interface and a properly governed Published Language takes real upfront design work - the upstream team has to think about what any future consumer might reasonably need, not just the one consumer in front of them today, and has to commit to change-management discipline like deprecation windows and versioning once the language is published, since many consumers now depend on it simultaneously. Below roughly three independent consumers, this fixed cost usually exceeds the savings versus just negotiating separate Customer-Supplier contracts, which can be more tailored and cheaper to build for a small number of known consumers. ## The common failure mode The most common failure mode is exactly the situation the question describes: a team stands up a shared API - the OHS half is technically present - but treats its data format as an implementation detail that shifts freely alongside internal refactors, with no real versioning policy and no deprecation window before a breaking change ships. Field names get renamed, enum values get added or removed, and every consuming team discovers the change only when their own integration breaks in production. This produces exactly the kind of ad hoc, per-consumer firefighting that OHS was supposed to eliminate by replacing it with one governed contract - the service scaled, but because the language wasn't actually published and protected, the coordination cost just moved downstream and multiplied across every consumer instead of disappearing. ## A concrete pattern A concrete real-world pattern: a company's central payments-processing context, once consumed by eight internal teams each with a separately negotiated integration, moves to a single well-documented REST API described by a versioned OpenAPI specification, with a formal policy that any breaking change requires a new major API version and a defined deprecation period for the old one. The OpenAPI specification itself is the Published Language artifact - reviewable, diffable, and something every consuming team can validate their own integration against automatically - while the REST API endpoints are the Open Host Service delivering it. New consuming teams can now integrate by reading the specification and writing against it directly, with no bespoke negotiation required at all, which is the payoff the pairing is designed to produce.