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 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 some pros and cons of using industry standards as the foundation for this common 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, or 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.
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 Published Language (PL) indeed forms a boundary around an integration-oriented model and its language, tailored for a specific purpose. This characteristic aligns closely with the concept of a Bounded Context in Domain-Driven Design. As such, it’s reasonable to consider the PL as a specialized type of Bounded Context.
This perspective naturally leads us to the related concepts of Interchange Context, Integration Context, and Interface Context. These are all specialized forms of Bounded Contexts that focus on facilitating communication and integration between different parts of a system or between systems.
Naming Things
The naming of some DDD concepts raises questions. For instance, what does “Published” mean in the term Published Language (PL)? One possible explanation is that the PL “publishes” the public model of a Bounded Context, acting as a public protocol. But wouldn’t “Public Language” be a more fitting name? Additionally, a PL goes beyond just referring to technical formats like XML, JSON, iCal, Avro or Protobuf. Its primary role is to define a shared and consistent understanding, including the semantics, between bounded contexts.
Similarly, what does ‘Open‘ mean in Open Host Service? 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?
Another example is ‘Ubiquitous Language’. Since ‘ubiquitous’ means ‘present or existing everywhere’, one might think of the Ubiquitous Language as an organization-wide language or even a canonical data model. This is incorrect. The Ubiquitous Language is actually a language that is limited (or bounded) by its Bounded Context. So, from this perspective, the Ubiquitous Language is not ubiquitous in the broad sense, but only ubiquitous within its specific context. With regard to the old ambition of a canonical data model: with DDD, the goal is to develop localized canonical models within bounded contexts that are more adaptable than a rigid, conventional enterprise-wide canonical data model (CDM). There are always multiple models.
Bounded Context and Ubiquitous Language are two of the most important concepts in DDD and can be challenging to grasp. We would like to include the Published Language in this category as well
Interface Bounded Context
Text
Interchange Context
The term ‘Interchange Context’ 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 Interchange Context 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 in this point-to-point connection.
Vlad Khononov 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 specifically designed for integration purposes. As in the previous case, the Published Language (PL) is not involved.
Eric Evans (and also here) describe the IC as a solution to the problem that arises when a domain language developed for the internal logic of a specific bounded context becomes the dominant interchange language between different bounded contexts. The following is an excerpt from Eric’s presentation: consider the following context map:
Figure reference: DDD & Microservices: At Last, Some Boundaries! • Eric Evans • GOTO 2015 (youtube.com)
In the upper part of the picture, we see that messages in the Ubiquitous Language of context A are exchanged between contexts E, D, C, and B (and A). The language of A has become the interchange language between multiple bounded contexts. Note that contexts E and D are communicating using the language of A, even though A is not directly involved in their communication. The issue here is that the language of A was primarily designed to address internal problems within A and to facilitate the partnership with context B. However, contexts E, D, and C may not be concerned with the internal logic of A or its collaboration with B.
The language of A has inadvertently become the dominant language that other contexts either translate into or conform to, shifting from a Ubiquitous Language to a Published Language. The problem now is that the language of A cannot be changed without affecting the other contexts that are using it, resulting in tight language coupling. A change in the language of context A 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:
Figure reference: DDD & Microservices: At Last, Some Boundaries! • Eric Evans • GOTO 2015 (youtube.com)
Note that in Eric’s presentation both the terms UL and Pl are not used. The IC also called Interchange Context and not Interchange Bounded Context as opposite to Interface Bounded Context (Zimmermann). It doesn’t solve a complex business problem, but it’s more a method of visualizing languages dependencies and identifing coherent sets of miscroservices that know how to talk to each other. The IC is particularly useful in microservices architectures where multiple services need to communicate effectively. Athough there are similarities between IC and PL, we consider them different concepts:
- Purpose: PL – Provides a standardized way for different bounded contexts to communicate and share data / IC – Facilitates communication between specific bounded contexts, acting as a translation layer
- Scope: PL: Often broader in scope, potentially industry-wide or organization-wide / IC – More focused, usually applying to a specific set of related contexts within an organization
- Implementation – Published Language is often implemented as a standard or specification, while Interchange Context is typically implemented as an actual software component
- Adaptability: Interchange Context can be more easily adapted to specific needs, while Published Language tends to be more stable
In summary, while both patterns aim to facilitate communication between bounded contexts, the Published Language is more about establishing a common vocabulary, while the Interchange Context provides a more active, mediating role in translating between specific contexts. An Interchange Context might use a Published Language as part of its implementation
- IC emerge on their own
- IC contributses to the interaction of BC’s to getting a bigger business process done and make that explicit
Evans talks about IC here also