Note: The following content represents personal insights and is not an exhaustive guide. It may contain inaccuracies or incomplete information.
Strategic Monoliths and Microservices by Vaughn Vernon and Tomasz Jaskuła is essential reading for understanding the concept of Published Language in Domain-Driven Design (DDD). The book explores how Published Language serves as a contract between bounded contexts, enabling clear and consistent communication within a distributed system. It also examines the balance between adopting industry standards and maintaining domain-specific flexibility, highlighting the challenges of rigid standardization and the benefits of a more contextual approach. By reading this book, you will gain a better understanding of the concept of Published Language.
This article presents our interpretation and analysis, combining theory and practice, and discusses the advantages and disadvantages of using an industry standard as the foundation for composing a Published Language.
Introduction
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.
Defining the PL may involve adopting (inter)national industry standards – terminologies and conventions that are 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, reduced flexibility and misalignment with specific use cases. Finding the right balance between adopting standards and maintaining domain-specific flexibility is essential – an issue explored in Vaughn Vernon’s and Thomasz Jaskula‘s book, Strategic Monoliths and Microservices, which has inspired this article.
For years, we have experimented with an industry-standard-based Published Language (PL) at Enexis, with mixed results. In this article, we will examine the role of PL in Domain-Driven Design (DDD), explore the pros and cons of using industry standards as its foundation, and connect these concepts to our own challenges.
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 lingua franca. 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.
Regarding team communication and dependencies (as described by Conway’s Law), the Published Language (PL) pattern, compared to other context map patterns, focuses promoting team independence and loose coupling. Autonomous and 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. 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.
In contrast to the traditional goal of a canonical data model (which will be discussed below), DDD emphasizes the development of localized canonical models within Bounded Contexts. These models are more flexible than the rigid, enterprise-wide canonical data model (CDM).
As Evans (GOTO 2015) notes:
There are always multiple models
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 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:
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 Apitchaka Singjai, Uwe Zdun and Olaf Zimmermann. 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 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. This international standard is actively used as a standardized inter-organizational exchange language
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 answer to the above is: not necessarily. The book Strategic Monoliths and Microservices 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: an internal standard governed by principles within a specific business entity, defining standards for external and potentially internal-organizational exchanges
- Context or subdomain level: individual standards defined by the Bounded Contexts or subdomains that other contexts and domains must use
These three main types vary in how they handle parameters like complexity, dependency, and flexibility, and others. A possible list (inspired by Strategic Monoliths and Microservices and Domain-Driven Design: Tackling Complexity in the Heart of Software) might be:
- complexity: the level of generality in the schemas compared to their focus on specific needs within a domain
- governance: the processes (ceremonies) and controls (consortia) required to manage and evolve the standard
- dependency: teams depend on external parties to define and change the standards
- flexibility: the extent to which changes in the schema can be quickly implemented
- consumer driven: contract-first design in in collaboration with consumers
- interoperability: whether the design prioritizes interaction with other systems or domains, or focuses more on internal coherence
- adoption effort: the effort and learning curve required to implement and adhere to the standard
- one-size-fits-all: the degree to which a standard or schema is designed to be universally applicable versus tailored to specific contexts or use cases
- overhead: the effort required to align the Ubiquitous Language of a specific Bounded Context with the Published Language type
When we apply these parameters to the three types Published Languages, we might come to the following bubble matrix below The size of each bubble indicates the level of relevance (e.g., the Bounded Context/Subdomain tier is the most flexible, allowing for rapid changes and adaptations):
Some observations:
- (Inter)national standards are typically more complex due to their broad applicability and have strong governance mechanisms in place due to their wide usage and formal processes
- (Inter)national standards prioritize interoperability with external systems or domains. Organizational standards focus on external consistency but may have some degree of intenal interoperability. The Subdomain/Context tier is often less concerned with interoperability, focusing on internal coherence
- Subdomain/Context type is often highly consumer-driven, focusing on the specific needs of teams or consumers
- A Published Language is shaped both by the needs of external Bounded Contexts and by the Ubiquitous Language of your own Bounded Context. The challenge lies in minimizing overhead while reconciling these requirements when the Published Language is dictated by an (inter)national standard
Conformist
As stated before, the Open Host Service (OHS) is an API designed to serve many consumers. The OHS pattern is particularly relevant in scenarios where consumers hold significant influence. Often, downstream clients dictate the functionality and the design of information exchange schemas. In API design, this approach is referred to as Consumer-Driven Contracts – a strategy in which the API’s consumers define their expectations and requirements for the API provider, or upstream supplier.
Frequently, the upstream supplier’s Open Host Service implements a Published Language. However, when the Published Language is an (inter)national standard, the upstream supplier is not the sole authority over the standard. This is illustrated by the dependency and governance parameters in the comparison table above: suppliers depend on external bodies for changes or updates, and strong governance is maintained since standards are managed by international organizations with formal change processes.
This is problematic for exchanges inside the organization’s enterprise of systems: on one hand, the design of the Open Host Service is driven by specific internal consumer requirements; on the other hand, the model of the Open Host Service is dictated by an external (inter)national standard. We could perhaps say that the Interchange Context is a conformist of this (inter)national standard. When we include the (inter)national Standard as context S in Eric Evans’ context map, the following visualization emerges:
There is tension and context coupling in this model; changes to context S directly impact contexts C and E. Positioned downstream of context S but upstream of the other contexts, interchange context I plays a pivotal role in the context map, as the model of S is propagated to other contexts through I. This highlights the critical importance of the stability of context S.
(Inter)national standards benefit greatly from stability due to their role in ensuring interoperability, but changes to the standard are never ruled out. Furthermore, they are often rigid, complex, and occasionally cumbersome, with their agenda ceremonially determined through international collaboration.
Is it strategically sound to adopt an (inter)national standard as the basis for an interchange language within organizational boundaries?
Canonical Model
As discussed, the book Strategic Monoliths and Microservices provides several examples of international schema standards used across various industries, along with the following statement:
There are obvious trade-offs when using such standards, but one important thing to note is that using the beefy canonical models has a definite disadvantage for internal enterprise use. These models are not only more difficult to adhere to, but also carry a lot higher transport overhead. If the enterprise is on the cloud, this will have an impact on cost.
In Domain-Driven Design (DDD), a canonical data model is often considered an anti-pattern, particularly when applied across all Bounded Contexts at an enterprise level. The canonical, or God Model, directly contradicts key DDD principles, especially the concept of Bounded Contexts. Bounded Contexts emphasize separating models based on specific business domains or subdomains. A God Model disregards this separation by attempting to create a single, unified model for all domains, leading to tightly coupled “God classes” that conflict with the DDD approach of tailoring models to fit specific contexts and their unique needs. However, if the canonical model is restricted to common data elements shared across Bounded Contexts, it avoids becoming a God Model or an Overly Complex Model.
In DDD, canonical data models are not inherently bad, but trying to enforce a single, enterprise-wide canonical model across all domains can create more problems than it solves. DDD advocates for localized, context-specific models that are more flexible and aligned with the needs of the business.
Dutch Energy Sector and the Evolution of Integration
The Dutch Energy Sector is undergoing a significant transformation, with many organizations, including Enexis, adopting new ways of structuring their teams and integrating their systems. A key principle driving this shift is organizing teams around business capabilities rather than technology. Inspired by the Inverse Conway Maneuver, this approach ensures that an organization’s structure is intentionally designed to reflect and support the desired system architecture. By fostering diverse skill sets within each team and minimizing dependencies, organizations reduce the need for excessive inter-team communication, enabling teams to work more efficiently while promoting a cohesive and adaptable architecture.
In parallel, integration architectures have also evolved significantly in recent years, shifting from rigid, centralized models to more distributed and agile approaches. These changes support greater flexibility, scalability, and resilience, enabling organizations to better adapt to the dynamic energy landscape. Key trends shaping this evolution include:
- Distributed and Agile Architectures: traditional, monolithic integration models are being replaced by decentralized and system-specific approaches. Organizations now embrace flexible integration patterns that enhance agility and reduce bottlenecks
- API-First and Microservices: the rise of microservices challenges the dominance of centrally created and maintained integrations. Instead, organizations are moving toward autonomous services that interact through well-defined APIs, fostering modularity and scalability
- Cloud Transition: integration architectures are increasingly adopting a hybrid approach, with integrations running across geographically distributed clouds and self-hosted environments. In this model, transmitting large canonical datasets is discouraged, and data transfer is minimized to enhance efficiency
- Flexibility and Scalability: modern integration architectures prioritize adaptability and scalability, ensuring that systems can evolve in response to changing business needs and technological advancements
- Event-Driven Architectures (EDA): real-time, event-driven integrations enable systems to react to changes as they occur, reducing dependencies and increasing resilience in distributed environments
- Domain-Driven Design (DDD): the adoption of DDD principles is reshaping integration architectures by aligning them with specific business domains. This shift away from centralized control reduces rigidity, allowing for greater autonomy and decentralized decision-making within each domain
The combination of team autonomy and the evolution of integration architectures highlights the limitations of the canonical data model approach. Many (inter)national standards function as canonical data models but often prove to be a “one-size-fits-none“ solution. These standards are typically centrally controlled and governed, making them impractical as a Published Language within organizational boundaries.
Using complex (inter)national standards as the foundation for a Published Language within an enterprise increases cognitive load and creates unnecessary friction for autonomous teams. Instead, organizations should adopt a pragmatic approach to integration, focusing on flexible, domain-specific interchange standards that support decentralized decision-making and team autonomy.
Enexis
Enexis has developed a central Common Data Model (CDM) based on international standards such as CIM and OASIS UBL, which was intended to serve as a common interchange language within the organization.
However, this theoretical CDM approach has not been effective as expected. Main reasons are:
- Heavy reliance on specialized knowledge from the single, centralized CDM team
- Limited flexibility: the CDM has been imposed top-down on development and integration teams, requiring every service to conform to a single data model
- Extensive organization-specific extensions despite being based on industry standards. For instance, one of our primary standards, CIM, does not cover a significant portion of the activities and data relevant to distribution network operators like Enexis. As a result, many extensions had to be added, which are difficult to design, maintain, and validate. Creating these extensions requires knowledge transfer from domain experts across the organization to the few members of the central CDM team
- Misuse and misinterpretation of the CDM, where parts of the model are often applied to use cases that almost fit but not entirely
Due to these challenges, the CDM approach has led to overly complex integrations that are difficult to evolve and maintain.
To promote team autonomy and create more flexible, adaptive integrations, a hybrid approach will be adopted. Less centralization will empower independent teams to decide on the most suitable solutions for their needs. Teams, organized by Bounded Contexts, should have the freedom to choose their own digital exchange standards rather than being forced into a top-down decision to adopt a single canonical data model. While critical data entities requiring standardization still necessitate collaboration between different bounded contexts within the organization, not everything must adhere to the same organizational or international standards. Flexibility is key in this approach.
Regarding the previously mentioned Published Language Types, we are shifting from the (inter)national level to the Bounded Context/subdomain level. This transition promotes a more flexible and adaptable approach to Published Languages, enabling faster integration updates, greater team independence, and a more consumer-driven model. The rigid processes (ceremonies) and controls (consortia) required at the (inter)national level are no longer necessary, allowing us to focus instead on a partnership or customer-supplier context map pattern that incorporates a Published Language.
We have realized that most of our internal Enexis services do not require Published Languages at the (inter)national level. In many cases, these integrations could have been just as robust—if not more so—when defined at the Bounded Context/subdomain level.
By defining the Published Language at the Bounded Context or subdomain level, teams can tailor it precisely to their specific use cases in collaboration with consumers. In practice, this approach allows services with many consumers to adopt a conformist model, while those serving a few specific consumers can move toward a partnership model.
That said, (inter)national Published Languages still have potential benefits for services extending beyond the internal Enexis landscape. For example, core services of distribution network operators adopting an (inter)national PL could significantly improve interoperability between (inter)national network operators.
The exchange standards, defined by Bounded Contexts, are maintained in a Schema Registry: central repository of schemas that define the structure of messages (e.g., events, commands, or documents). By formalizing the structure of communication, a Schema Registry aligns with DDD’s strategic design principles, enabling teams to collaborate effectively while keeping their contexts decoupled and autonomous. A great example of a Schema Registry is the open source XOOM Schemata component: Schemata | VLINGO XOOM.
TL;DR
What can we take away from this post?
- avoid using (inter)national industry standards as the foundation for an organization’s Published Language(s)
- treat the public API or external interface of a system as its own distinct interface bounded context
- design APIs with a minimalistic mindset
- consider the customer-supplier context map type to establish consumer-driven contracts
- use a Published Language for commonly exchanged data or when multiple downstream bounded contexts are involved. Let the need for it emerge naturally!
Strategic Monoliths and Microservices tackles the ongoing debate of whether to opt for a monolithic architecture or join the many others jumping on the microservices bandwagon. The authors challenge the lingering hype around microservices with a dose of reality. They clarify the distinction between a tangled “big ball of mud” and well-structured modular monoliths (“modulith”), while also outlining the context and motivations that justify a move to microservices. Additionally, in our opinion, the orange cactus book 🙂 provides some of the clearest and most practical explanations of context mapping and how to apply them in real-world scenarios, particularly the Published Language context map pattern. Looking forward to the next book Implementing Strategic Monoliths and Microservices.
Originally published on: The Published Language and Industry Standards in Domain-Driven Design