Anti-corruption layer pattern allows communication between one system or subsystem to another system or sub system without corrupting each other system domain or model or the objectives.
Technically Anti-corruption layer is made of multiple different patterns like Facade and Adapter Pattern. Layer can have own set of patterns to satisfy the need but here I’m going to take an example where I’ll be using most popular patterns Facade and Adapter to build the Anti-Corruption layer.
Problem: Assume we have a legacy Banking system and we plan to upgrade the system gradually or adding new enhancements.
Challenge: Being the system legacy doesn’t allows us to be inline with latest technology stack easily. For simplicity assume, the legacy system has set of API services which is interacting using SOAP. i.e.
Now we have a challenge with upgrading the system. i.e. converting the individual services (gradually all) to REST services OR having a new Client system (an mobile app) relying on REST and allows the communication with the legacy system. Lets see how we can solve the problem using Anti-Corruption layer pattern and how we can build the layer without affecting the existing legacy and live with the both the system New and Legacy.
Solution: Assume we have a new client application which can only deal with REST APIs. Hence we need a bridge which can help to enable the communication between new and legacy without affecting the each other system. So this is what we can do by building Anti-Corruption Layer using Facade and Adapter patterns.
As per above diagram, We have three components in our Anti-Corruption Layer and they are:
- Rest API Layer: REST APIs for different services. We need this as our new system can deal with only REST protocols.
- Adapter Pattern: This layer will help us to translate the message between two different protocols REST & SOAP.
- Facade Layer: This layer will actually make the SOAP calls to the legacy.
With this approach we solve the problem without making any change to the legacy system.
The Anti-Corruption layer here, can be implemented as a component within the application or as an independent service and can be hosted independently. In benefit, it can manage the traffic by its own and can be scaled in or out accordingly.
Pros & Cons of the Anti-Corruption layer pattern:
Cons: Because of the added extra added layer, this may add latency to calls made between the two systems and also it’s introducing extra services which should be managed & maintained apart from the system
Pros: Easily allows to enable the interaction between two systems which are not compatible to each other with without corruption their domain, model and objectives.
Considerations:
1. Consider if you need one or more Anti-Corruption layers.
2. Consider the effort and plan from development to release and then maintenance of this.
3. Consider the hosting plan, whether this could be a standalone component and then taking care of scaling Or this will be a part of existing system.
4. Decide if this would be temporary or permanent or will be retired after all legacy functionality has been migrated and plan accordingly.
When to use this pattern
Use this pattern when:
- A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained.
- Two or more subsystems have different semantics, but still need to communicate.
This pattern may not be suitable if there are no significant semantic differences between new and legacy systems.
Hope you like it. Thank You for reading.
Reference: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
