Published Language Pattern
A published language is a translation language shared between bounded contexts as a documented, versioned standard, so that integration goes through one well-defined schema instead of N pairwise.
Definition
A published language is an integration pattern where a shared, documented, versioned translation language — often a standard schema or industry vocabulary — is used as the exchange format between bounded contexts, so that each context translates to and from the published language rather than maintaining N pairwise converters.
Context and scope
Applied in industry-standard schemas (HL7, FHIR, ISO 20022), open API ecosystems, and any multi-context integration where pairwise translation does not scale.
Common misconceptions
- A published language is a shared kernel — a shared kernel is a shared model two contexts own; a published language is owned by neither and consumed by both
- A published language eliminates translation — it reduces translation to two per context instead of N pairwise; it does not eliminate it
Anti-patterns
- Publishing a language and letting one context change it unilaterally, breaking every other context that consumed the published form
- Using a published language so verbose that every context writes a private shorthand and the published form is only used on the wire
Related concepts
Authoritative source
What it is
A published language is an integration pattern where a shared, documented, versioned translation language — often a standard schema or industry vocabulary — is used as the exchange format between bounded contexts, so that each context translates to and from the published language rather than maintaining N pairwise converters. Applied in industry-standard schemas (HL7, FHIR, ISO 20022), open API ecosystems, and any multi-context integration where pairwise translation does not scale. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.