Maintaining Purity

Once a team has defined its bounded contexts, modules, or microservices, the team is going to implement interactions between them. It is time to think of how those interactions have to occur.

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

Let us imagine 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 created by the DDD team. In this case, it would be necessary to create a coupling between Transfers and the external service. It is crucial to avoid some 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 that translates a bounded context model into an external model and vice versa. One of the most important things when implementing components based on Domain Driven Design is to avoid corrupting business logic in any way. Once core business logic is implemented, it will need to interact with external components. It is impossible to implement any external connection from the domain logic. To achieve it, the anti-corruption layer exists, which can be implemented by using some design patterns such as Facade, Adapter, or even by coding a custom translation.