Create a facade/adapter layer between different subsystems that do not share the same semantics.
Problem
How to introduce large changes to the models and the architecture of the application, when you do not have the luxury to start a project from scratch? How to start creating new models, but continue to use legacy parts of the application as well?
Solution
Isolate the different subsystems by creating the anti-corruption layer between them. This is especially useful when preventing legacy domain models from polluting new domain models. Legacy subsystem does not have to be changed, and new subsystems can be created without considerations for the old systems. In this case, the anti-corruption layer is just a temporary subsystem that is just a step in the bigger strangler pattern strategy.
The anti-corruption layer does not have to be temporary. Sometimes, it's just not realistic to change large parts of the codebase. In those cases, it can still make sense to create and maintain the (semi)permanent anti-corruption layer. Why use old coding standards for creating new functionality? Create a new sub-system from scratch and make it communicate with older parts of the system with the anti-corruption layer.
Considerations
- The anti-corruption layer adds additional complexity to the system. However, in the long run, it should make the system easier to use.
- Depending on the implementation and the system, the anti-corruption may slow down the entire system, by adding latency between calls.
- Be careful with designing the anti-corruption layer, even if it is temporary. It may not scale well enough.
- How are you going to manage the anti-corruption layer in the medium and long term?