For stateless model translation, the bounded context that owns the translation (OHS for upstream, ACL for downstream) implements the proxy design pattern to interject the incoming and outgoing requests and map the source model to the bounded con‐ text’s target model. This is depicted in Figure 9-1.

Figure 9-1. Model translation by a proxy

Implementation of the proxy depends on whether the bounded contexts are commu‐ nicating synchronously or asynchronously.

Synchronous

The typical way to translate models used in synchronous communication is to embed the transformation logic in the bounded context’s codebase, as shown in Figure 9-2. In an open-host service, translation to the public language takes place when process‐ ing incoming requests, and in an anticorruption layer, it occurs when calling the upstream bounded context.

Figure 9-2. Synchronous communication

In some cases, it can be more cost-effective and convenient to offload the translation logic to an external component such as an API gateway pattern. The API gateway component can be an open source software-based solution such as Kong or KrakenD, or it can be a cloud vendor’s managed service such as AWS API Gateway, Google Api‐ gee, or Azure API Management.

For bounded contexts implementing the open-host pattern, the API gateway is responsible for converting the internal model into the integration-optimized pub‐ lished language. Moreover, having an explicit API gateway can alleviate the process of managing and serving multiple versions of the bounded context’s API, as depicted in Figure 9-3.

Figure 9-3. Exposing different versions of the published language

Anticorruption layers implemented using an API gateway can be consumed by multi‐ ple downstream bounded contexts. In such cases, the anticorruption layer acts as an integration-specific bounded context, as shown in Figure 9-4.

Figure 9-4. Shared anticorruption layer

Such bounded contexts, which are mainly in charge of transforming models for more convenient consumption by other components, are often referred to as interchange contexts.

Asynchronous

To translate models used in asynchronous communication you can implement a mes‐ sage proxy: an intermediary component subscribing to messages coming from the source bounded context. The proxy will apply the required model transformations and forward the resultant messages to the target subscriber (see Figure 9-5).

Figure 9-5. Translating models in asynchronous communication

In addition to translating the messages’ model, the intercepting component can also reduce the noise on the target bounded context by filtering out irrelevant messages.

Asynchronous model translation is essential when implementing an open host ser‐ vice. It’s a common mistake to design and expose a published language for the mod‐ el’s objects and allow domain events to be published as they are, thereby exposing the bounded context’s implementation model. Asynchronous translation can be used to intercept the domain events and convert them into a published language, thus pro‐ viding better encapsulation of the bounded context’s implementation details (see Figure 9-6).

Moreover, translating messages to the published language enables differentiating between private events that are intended for the bounded context’s internal needs and public events that are designed for integration with other bounded contexts. We’ll revisit and expand on the topic of private/public events in Chapter 15, where we dis‐ cuss the relationship between domain-driven design and event-driven architecture.

Figure 9-6. Domain events in a published language