DEV Community

Discussion on: The Anti-Corruption Layer Pattern

thorstenhirsch profile image
Thorsten Hirsch • Edited on

Well, there's another option. There's actually a whole IT sector focusing on application integration. If you're lucky your company has an EAI system (enterprise application integration), sometimes called ESB (enterprise service bus) that will do the "no fun" things for you. I am working as an EAI developer myself and we have the following goals:

  • replacing an integrated application shall have no effect on other applications (only the EAI interfaces must be adapted to the new application)
  • versatility: the EAI platform supports all required protocols and integration patterns
  • monitoring: all data flows must be tracked (so that the data owners know who else received their data)

The anti-corruption layer in Logistics violates our 1st rule, because it implements the Warehouse interface. Here's what an EAI solution would look like:

  • implement the Warehouse interface
  • implement the Logistics interface
  • implement a mapping between Logistics and Warehouse interface

Sounds pretty similar to the anti-corruption layer? Yes, but the result is a passive component running on the EAI platform that can even support different protocols (think of "message-oriented-middleware"), so Logistics might call the EAI via REST and the Warehouse might want to receive a CSV file. But most important is that neither application depends on the other, because none of them has implemented the interface of the other.

An EAI platform might not be worth it when you only have a handful applications talking to each other and compare the development effort (and the additional costs for the EAI). But the aspect of making the data flows between your applications transparent is really of great value and makes an EAI platform attractive even if you pay a bit more in sum.

rafalpienkowski profile image
Rafal Pienkowski

@thorstenhirsch , I agree with our comment. In the case where different modules communicate each other (no matter how: SOAP, REST API, flat files, etc.) or in the enterprise world (where the budget is high enough to buy and maintain such kind of ESB system) using EAI platform brings a lot of benefits (as you mentioned).

On the other hand, when I'm working in a bigger team, and there is no need for usage out of process communication, I think that the Anti-Corruption Layer (ACL) is more convenient. Teams can develop their libraries/packages independently without affecting models in my part of the system, as it was described in this article.

To sum up, depending on the project size and communication type (in/out of process) EAI platform and ACL can be used interchangeably and/or in conjunction.