Why to use ACL the Anti Corruption Layer
The ACL is a layer that translates the language of external bounded context API or external vendor API into its own language. In some cases such as statuses and error codes might stay the same. That might suggest that this whole translation doesn’t make any sense. I will prove that it does.
When to use ACL?
- The short answer is always when you consume external API.
Imagine a situation when you need to implement phone verification. You need to use some third-party vendor that provides you with the functionality of spending SMSs with OTP. In Domain Driven Design such functionality will probably be located inside the bounded context responsible for identity management, authorization, and authentication. For the sake of example, let’s call it “Identity management” bounded context. The high-level architecture will look like this:
Such functionality of verifying phone numbers can be used in many places, for example during onboarding, to authorize sensitive changes in the user profile, or to authorize a bank transfer. Let’s imagine that there is another bounded context responsible for processing bank transfers, let’s call it the “Bank transfer processing” bounded context. There must be a backend service that is responsible for processing transfers and some BFF that serves the nice API for web and mobile apps. The high-level architecture will look like this:
Now, imagine that the phone verification service simply proxies the statuses and error codes from an external vendor and exposes it in its API. The bank transfer service does the same, and the BFF does too. Both mobile and web apps hardcode these statuses and error codes. The dependency tree will look more or less like this:
We have no control over the vendor’s API at all, so imagine what will happen if they decide to change the API. Ok, API is versioned, they shouldn’t do a backward incompatible change… But at some point, the API version might get deprecated, and later on… removed. So, upgrading the API will require changes in the phone verification service, bank transfer service, the BFF, web app, and… Force update apps since they hardcoded the statuses and error codes.
The phone number verification service will probably be storing each verification with the status, error codes, etc. If any of that changes there will be inconsistency in the data. The data analysis reports might break as well.
What benefits the ACL usage bring?
In desired architecture, the phone verification service should isolate the external API and translate its statuses into its own ones, even if initially the internal statutes are the same as the external ones. Since the Bank transfer service belongs to another bounded context it should implement its own ACL as well. Again, at the beginning statuses might be the same. But, maybe we would like to hide some technical details and expose only a few statutes out of all in the bank transfer service. Maybe there is no need to handle all error codes or some of them can be mapped into one error code. Taking this approach the dependency tree will look like this:
Coming back to the example of deprecating API, if the external API changes, for any reason, the only place that needs to be changed is the phone verification service. It will map the new statuses to keep the contract and no other changes should be done. The team that owns the Bank transfer bounded context shouldn’t even be aware that such a change has happened.
If you’re interested in learning more about Xapo Bank — Bitcoin Bank providing simple and safe usability to retail customers, explore the resources at xapobank.com.
