Note: The following content represents personal insights and is not an exhaustive guide. It may contain inaccuracies or incomplete information.
In Domain-Driven Design (DDD), the Published Language (PL) refers to a shared vocabulary that facilitates interaction between two or more Bounded Contexts. It makes it possible for different contexts to integrate or exchange information using a well-documented and agreed-upon model designed to meet integration needs. This approach improves the exchangeability of relevant information, promotes clarity, and supports interoperability between distinct parts of the system by providing a common, standardized language for cross-context interactions.
One way to define the PL is by adopting industry standards – terminologies and conventions widely recognized within a specific domain. While these standards can enhance consistency and interoperability, they may also introduce drawbacks, such as: unnecessary complexity, the involvement of consortia, resistance to change, and reduced flexibility. Finding the right balance between adopting standards and maintaining domain-specific flexibility is essential, a challenge explored in Vaughn Vernon’s and Thomasz Jaskula‘s book, Strategic Monoliths and Microservices, which has inspired this article.
In the following sections, we will explore the concept of PL in DDD and examine the advantages and disadvantages of using industry standards as the foundation for a shared language.
What is the Published Language?
The Published Language (PL) is a context mapping type, or Bounded Context integration pattern, that defines a well-documented, shared language between Bounded Contexts. Each context can translate to and from this language. It is often used with an Open-Host Service (OHS) to provide a public API for multiple clients. An OHS is typically designed to serve multiple downstream consumers. External events (events published outside the Bounded Context) should also be defined using the PL.
The purpose of the PL is to serve as a shared interchange language between contexts. By serving as an independent integration model, it remains decoupled from the internal implementation of a Bounded Context, providing both stability at the interface layer and flexibility for the domain model. This approach not only decouples the models but also the languages: changes in a Bounded Context’s Ubiquitous Language (UL) do not affect the PL.
In terms of team communication and team dependencies (as described by Conway’s Law), compared to other context map patterns, the Published Language (PL) focuses on promoting team independence and loose coupling. Free teams work with Separate Ways and Published Languages:
Picture source: Introduction to Context Mapping – Michael Plöd – DDD Europe 2022
It’s worth noting that the PL is a simplified integration model designed to abstract away the complexity of the underlying Bounded Context domain model, making it easier for other contexts to interact without being burdened by that complexity (encapsulation).
The PL establishes a boundary around an integration-oriented model and its language, tailored for a specific purpose. This closely aligns with the idea of a Bounded Context in DDD, making it reasonable to consider the PL as a specialized type of Bounded Context. In DDD literature, we encounter terms such as Interchange Context or Interface Bounded Context. But what do these terms actually mean? How do they differ, overlap, and relate to the concept of Published Language?
Naming Things
The naming of certain DDD concepts can lead to discussion. For example, what does Published mean in the term “Published Language (PL)”? One interpretation is that the PL “publishes” the public model of a Bounded Context, making it (publicly) accessible and including a well-documented description of that model. However, a Published Language is not limited to technical formats like XML, JSON, iCal, Avro, or Protobuf. Its primary purpose is to foster a shared and consistent understanding, including the semantics, between Bounded Contexts. That said, since the PL functions as a public protocol, wouldn’t the term Public Language be a more fitting choice?
Similarly, what does Open mean in “Open Host Service (OHS)”? Does “Open” refer to public accessibility and transparency like a public API or does it (also) refer to a shared protocol open to enhancements to handle new integration requirements? Since an Open Host Service should be well-documented by default, what is the additional value of a Published Language to the Open Host Service?
Another example is Ubiquitous Language. Since “ubiquitous” means present or existing everywhere, one might mistakenly interpret the Ubiquitous Language as an organization-wide language or even a canonical data model. However, this is incorrect. The Ubiquitous Language is confined to its specific Bounded Context, making it inherently limited in scope. The Ubiquitous Language is not “ubiquitous” in the broad sense but is ubiquitous only within its Bounded Context. It is the language that should be used everywhere (ubiquitously) within the Bounded Context: from initial discussions and domain modeling to the final implementation in code. While the Published Language (PL) serves as the public language for communication between contexts, the Ubiquitous Language (UL) should be understood as a private language within a specific context.
Regarding the traditional ambition of a canonical data model, DDD focuses on developing localized canonical models within bounded contexts. These are more adaptable than the rigid, conventional enterprise-wide canonical data model (CDM):
There are always multiple models (Evans GOTO 2015)
Bounded Context and Ubiquitous Language are two of the most critical concepts in DDD and can be challenging to fully understand. We believe that the concept of Published Language also falls into this category.
Interchange Context
The term Interchange Context (IC) is mentioned in Strategic Monoliths and Microservices and is used to describe a translation layer between systems and services. It translates local system events into SaaS-based API calls and SaaS-based feeds into events that the system understands. The term IC refers specifically to the idea of translating and mediating between distinct systems and services. The concept is similar to the idea of an Anti-Corruption Layer (ACL): translating one model to another. The Published Language (PL) is not involved and plays no role in this point-to-point connection.
Vlad Khononov in his magnificent book Learning Domain-Driven Design Aligning – Software Architecture and Business Strategy and Nick Tune describe the Interchange Context (IC) as a shared Anticorruption Layer (ACL) implemented through an API gateway that can serve multiple downstream bounded contexts. In these instances, the anticorruption layer functions as an interchange context as an integration-specific bounded context specifically designed for integration purposes. As in the previous case, the PL is not mentioned here. An interesting question to consider is: which team would take ownership of the IC?
Eric Evans describes the IC as a solution to the problem of a domain language designed for a specific Bounded Context becoming the dominant language for communication across multiple contexts. For example, in below context map (referenced from Evans’ QCon 2016 talk), the Ubiquitous Language of Context A is used as the interchange language between contexts E, D, C, and B. Even E and D communicate using A’s language, despite A not being directly involved.
Picture source: DDD & Microservices: At Last, Some Boundaries! • Eric Evans • GOTO 2015 (youtube.com)
This creates tight coupling, as A’s language – primarily intended for internal use and collaboration with B – was not designed for other contexts. Changes to A’s language can disrupt all dependent contexts and would result in breaking changes for other contexts.
The Integration Context (IC) introduces a specific interchange language designed for integration purposes, making it easier for other contexts to integrate. Furthermore, the language of A is decoupled from the language of the IC through an Anticorruption Layer (ACL), allowing the language of A to evolve independently:
Picture source: DDD & Microservices: At Last, Some Boundaries! • Eric Evans • GOTO 2015 (youtube.com)
Note that in Eric’s presentations on the Interchange Context (IC), neither the terms “Ubiquitous Language” (UL) nor “Published Language” (PL) are explicitly mentioned. Our interpretation is that the UL of Context A is no longer serving as the interchange language. Instead, the PL of Context I has taken over this role, as it is specifically designed for interchange purposes, making integration with other contexts simpler and more effective.. In this sense, the common language of Context I can be viewed as a PL. However, it’s important to note that a Published Language is not necessarily an Interchange Context, but rather a component of it.
Note also that the IC is referred to as the Interchange Context and not the Interchange Bounded Context, in contrast to the Interface Bounded Context described below.
The IC does not aim to solve complex business problems; instead, it serves as a method to visualize language dependencies and identify coherent sets of microservices that can effectively communicate. This makes the IC particularly useful in microservices architectures where multiple services require seamless interaction.
Although there are similarities between the IC and PL, they are considered distinct concepts:
| Published Language | Interchange Context | |
| definition | a shared, standardized language or protocol used for communication between bounded contexts. It ensures consistency and clarity when multiple contexts need to collaborate without tightly coupling their models. | a specific scenario where two or more bounded contexts interact to exchange data or services. It often involves defining how the integration occurs, including protocols, data formats, and translation mechanisms. |
| purpose | provides a standardized way for different bounded contexts to communicate and share data | aims to facilitate integration between bounded contexts, often using tools like an Anticorruption Layer to translate between models |
| scope | often broader in scope, potentially industry-wide or organization-wide | more focused, usually applying to a specific set of related contexts within an organization |
| ownership | not owned by any single bounded context but is agreed upon by all participating contexts or stakeholders, sometimes even aligning with industry standards (e.g., MathML, GML) | it focuses on the interaction mechanisms between specific contexts rather than creating a universal standard |
| implementation | often implemented as a standard or specification | typically implemented as an actual software component |
| adaptability | tends to be more stable | can be more easily adapted to specific needs |
In summary, both patterns aim to improve communication between bounded contexts, but they serve different purposes. A Published Language focuses on creating a shared vocabulary, while an Interchange Context actively mediates and translates between specific contexts. Our understanding is that an Interchange Context may incorporate a Published Language as part of its implementation.
Interface Bounded Context
The term Interface Bounded Context appears in academic publications on Microservice API design, published by Olaf Zimmermann and his team. In Practitioner Views on the Interrelation of Microservice APIs and Domain-Driven Design: A Grey Literature Study Based on Grounded Theory | IEEE Conference Publication | IEEE Xplore (2021) the question is posed How to Map the DDD Domain Model and its Elements to an API?
Based on a grey literature study (which includes practitioner views on this topic and research outputs that are not formally published through traditional academic study), six possible design options are identified as solutions to this question. One of these is the “Interface Bounded Context”: an additional, specialized Bounded Context that represents the exposed API interface. This solution is is positively evaluated for design decision drivers such as: encapsulation (the REST API should be separated from the domain model to avoid brittle and overly complex interfaces), API modifiability and usability. However, it is noted that the Interface Bounded Context requires more effort compared to the other proposed solutions.
In a subsequent publication: Patterns on Deriving APIs and their Endpoints from Domain Models | 26th European Conference on Pattern Languages of Programs (acm.org) the Interface Bounded Context is introduced as one of the variant patterns for deriving APIs and API endpoints from domain model elements. These contexts are distinct Bounded Contexts, specifically designed for creating APIs. In domain model design, an “Interface Bounded Context” is dedicated to defining the interface exposed by the API resulting in clearer separation between internal domain models and external interfaces. Note that in this article it is stated an API is a Published Language in DDD-terminology and the API contract (OAS) is a formal specification of the Published Language.
In summary, these articles emphasize the relationship between APIs (Open Host Services) and the use of a Published Language within its own Bounded Context. Our understanding is, that a Published Language can be understood as an Interface Bounded Context – a dedicated model for interface purposes that decouples the external interface from the internal model. This raises further questions: who holds sole authority over this model? Who defines it? And to what extent should an industry standard be considered when designing it?
Industry Standards
Standardized inter-organization exchange languages created by various industries serve as examples of Published Languages. For instance, Eric Evans highlights the Financial Information eXchange (FIX) Protocol, a financial industry standard, and the Chemical Markup Language (CML), an XML-based language designed as a common interchange format for the chemistry domain. Similarly, the book Strategic Monoliths and Microservices emphasizes additional examples of industry-specific Published Languages:
- GS1: a global, non-profit organization that develops and maintains standards for business communication. GS1 standards are widely used in industries such as retail, healthcare, logistics, and food services;
- HL7: (Health Level Seven International) is a global standards organization that focuses on creating frameworks and standards for the exchange, integration, sharing, and retrieval of electronic health information;
- ICD-9/ICD-10: are versions of the International Classification of Diseases (ICD), a system developed by the World Health Organization (WHO) to standardize the coding of diseases, symptoms, procedures, and other health-related information globally.
Widely recognized examples of Published Languages, as highlighted by the DDD Design Crew, include iCalendar and vCard. These standards are formally defined by the Internet Engineering Task Force (IETF) through the specifications RFC 5545 for iCalendar and RFC 6350 for vCard.
Picture source: GitHub – ddd-crew/context-mapping
Other real world examples of published languages are:
- MathML for representing mathematical formulas (standardized by W3C)
- GML (Geography Markup Language) for representing geographical features in geographical information systems (standardized by OGC)
- SWIFT (Society for Worldwide Interbank Financial Telecommunication) provides a standardized way for financial institutions to exchange financial messages
- The Common Information Model (CIM) is a standardized framework developed by the electric power industry to facilitate the exchange of information about electrical networks between application software. It has been formally recognized by the International Electrotechnical Commission (IEC) as a key standard in this field
From the above examples, it becomes clear that these standards are all governed and published by a consortium or steering committee that sets the industry standard. This raises the question: is the involvement of this consortium a prerequisite for a Published Language? Is a Published Language only considered a Published Language if it is published and governed by a consortium?
Types of Published Language
The book outlines three types or levels of Published Languages, categorized by the authority responsible for defining the PL model:
- (Inter)national level: industry-wide standards established by international or national working groups and endorsed by governing organizations (GS1, CIM etc)
- Organizational internal level: standards defined by an organization for both external and, possibly, inter-organizational exchanges
- Context or subdomain level: individual standards defined by the Bounded Contexts or subdomains that other contexts and domains must use