Reading Time: 2 minutes

In the past, I have had the opportunity to be part of projects with robust and complex systems that need to communicate with each other. But due to the lack of homogeneity of their technologies, it has become a headache for the development teams involved. This is where this pattern helps to overcome many of these obstacles. In this post, I want to share a quick and concise explanation about the anti-corruption layer pattern.

The anti-corruption layer pattern implements a facade or adapter between different systems with different semantics. The main purpose is to translate the request from one system to another, trying to reduce dependencies and limitations.

“Create an isolating layer to provide clients with functionality in terms of their own domain model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally the layer translates in both directions as necessary between the two models.”

— “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans

Context

Several companies dedicate their efforts to solving specific problems under specific mechanisms, technologies and architectures, forgetting a potential unification or communication of those systems in the future.

Many of these scenarios are present when trying to interface a new or recent system with legacy components, causing compatibility issues. In these cases, the priority must be to respect the restrictions of the system and not include bad practices in our code in order to force communication between those involved.

An ally to solve this problem is to implement an anti-corruption layer, which serves as an adapter and translator between the requests that the systems or subsystems involved make.

When to use?

If you do not have homogeneous systems, you can use this pattern in order to avoid mixing protocols and communication mechanisms between different architectures and subsystems.

Advantages

• A standard interface to expose functionality
• Evolving implementations without sacrificing compatibility or efficiency
• Discovering services may be easier through a middle layer
• Centralized error handling in the middle layer
• Moving and unifying communication, monitoring, security and interoperability responsibilities to a layer that does not interfere with legacy or new systems

Disadvantages

• The anti-corruption layer adds an effort in order to integrate with the entire system in terms of monitoring, configuration and deployment.
• The anti-corruption layer could add latency when processing calls and requests between systems.
• The anti-corruption layer is a candidate to become another component to scale. It is important to consider the strategy to scale it in order to avoid decreasing performance.
• Transaction processing and data consistency should be monitored.

In conclusion, I would recommend implementing this pattern under the following premises:

• Systems with different implementation technologies that need to communicate, evolve and expose their functionalities.
• Migration projects that need to connect legacy and new systems.