Distributed Application Architecture Patterns

11.1 Anti-Corruption Layer (ACL)

Mediate between modern and legacy systems

This pattern is based on the Anticorruption Layer1 defined by Evans [190, p. 364], later by Richardson [20, p. 446, 191], Deenadayalan [192] and Microsoft [193].

It has a similar notion to the Adapter2 pattern by Burns [65, later 22, p. 31], although the latter focuses predominantly on its usage in regards to enabling Health Monitoring and is deployed as a Sidecar.

Fowler’s Gateway [7, p. 466] can be seen as an implementation of this pattern [194, 195].

11.1.1 Context

An application needs to work with an external system that satisfies one of the following conditions.

  1. It uses outdated technologies that would bring in unwanted dependencies or are incompatible

  2. It has a poorly designed (corrupted) API

  3. It is impractical to change (e.g. a legacy system)

  4. It uses different model semantics

11.1.2 Solution

Implement an anti-corruption layer that isolates the two systems, acting as an intermediary that translates between them.

This layer can be a separate software or a different service (see fig. 34).

Figure 34: Anti-corruption layer (ACL)

11.1.3 Potential issues

Any data transformation inevitably causes increased increased latency. When scaling the system up, the ACL may become a bottleneck or a single point of failure. If the underlying service is scalable, the ACL has to be designed with that in mind.

If the ACL is implemented as an additional service, it adds maintenance cost. Furthermore, if it is a short-term solution, the ACL needs to be tracked as technical debt.

Lastly, there is a risk of persisting corruption – if the API of the ACL is poorly designed, the “corruption” will be propagated anyway.

11.1.4 Example

ExampleEshop uses an old warehouse system to manage its inventory. However, this warehouse system is old, uses legacy technologies and has a complex API in a foreign language. To decrease coupling and to prevent having to pull in legacy dependencies, the eshop uses an anti-corruption layer to translate between the two systems. This layer provides an API that uses the same semantics as the rest of the system, so developers working on the eshop do not need to know the intricacies of the warehouse system. This also means that once this system is replaced, the rest of the system will not need to be updated.

11.1.6 Further Reading

  1. Not to be confused with Access Control Lists, which have the same acronym↩︎

  2. Not to be confused with the well-known Adapter pattern by Gamma et al. [24]↩︎