Maintaining Purity

After a team defines its bounded contexts, modules, or microservices, the team proceeds to implement interactions between them. Now, it is time for us to think about how these interactions will occur.

Purity is all about maintaining a model away from something that may mess it up. For example, models of external applications, databases, legacy systems, and even models of other bounded contexts.

Let us imagine that there is a component called transfers that needs to obtain information from a third-party application. This external application does not follow the model of transfers that was created by the DDD team. In this case, it is necessary to create a coupling between transfers and the external service. However, it is crucial to avoid any type of coupling.

What is an anti-corruption layer?

The anti-corruption layer (ACL) is a strategic pattern in the DDD world. It is nothing but a translator, which translates a bounded context model into an external model and vice versa. One of the most important things to consider during the implementation of components, based on DDD, is to avoid corrupting business logic. Once the core business logic is implemented, it will need to interact with the external components. It is impossible to implement any external connection from the domain logic. The anti-corruption layer exists to help us implement this external connection. This layer can be implemented by using some design patterns, such as Facade and Adapter, or even by coding a custom translation.