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.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
@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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
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:
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.
@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.