How does the anti-corrosion layer work in DDD?

Gateway
In domain-driven design , there are several recommended architectures . But they all have a common feature: the outermost layer is a gateway (some are also called adapters).

Southbound and Northbound
For the gateway, it is actually divided into southbound and northbound. According to the concept of northbound and southbound, the northbound gateway corresponds to input, and the southbound gateway corresponds to output. For example, the controller interface, message queue monitoring interface, RPC interface, etc. provided by a service are all northbound gateways, which are used to accept and monitor other incoming requests; while a service calls the downstream DB, MQ producer, and http of other services. , RPC interface, etc., are all southbound gateways.

The role of anti-corrosion layer

Anti-corrosion layer service
The concept of anti-corrosion layer originally originated from DDD, and was later used in the architecture of microservices. As the name suggests, the main function of the anti-corrosion layer is to "prevent the architecture from rot". The principle of entropy increase is also applicable in the software field. With continuous iteration, the code and architecture will always tend to be chaotic. Therefore, it is necessary to consider in advance the future of this possible change and add a layer of anti-corrosion.

In microservices, the anti-corrosion layer refers to extracting a single service for anti-corrosion, which is mainly used in scenarios such as system migration. In DDD, the anti-corrosion layer can actually be called an "adaptation layer", which is used to isolate upstream and downstream dependencies.

^Anti-corrosion layer in microservices^
Anti-corrosion layer code
In addition to being a separate service, each microservice should also have its own anti-corrosion layer code.

In large teams, many microservices will be split. Due to various reasons such as business development or architecture upgrade, it is very likely that some services and some interfaces will be upgraded at a certain time. At this time, the general approach is to find the upstream and downstream dependencies, and then notify them to use the new interface.

But this brings up a problem: if an upstream service calls this interface in a large number of places in the code, the transformation cost will become very high, and this kind of transformation between systems is difficult to test and the risk is high. At this time, if the upstream service has its own adaptation layer before calling, then he only needs to change the code of the adaptation layer.

And if you can’t push forward the transformation of upstream services, you can also adapt within your own services. This can be regarded as the first layer of adaptation for the northbound gateway itself, but this approach is not very recommended, and it is not conducive to your own later iterations.

The recommended practice is: all southbound gateways should be adapted as much as possible, especially to call external interfaces; all northbound gateways should be as simple as possible, without adaptation, and the upstream should adapt themselves.

How to write anti-corrosion layer

The code of the anti-corrosion layer generally applies the "adapter pattern" . Generally, the interfaces exposed by other microservices will be provided to other microservices in the form of SDK. These services are generally called xxService and xxClient. The anti-corrosion layer code is a layer of packaging on this basis, generally called xxWapper and xxAdapter. Among them, Request and Response will also be included. But the workload of redefining a class by yourself is relatively large, so the original structure is generally reused directly by inheritance or combination, and when it is necessary to overwrite the field, a new field is defined on this basis, and then transferred Go to the new field.

For example, there is a field called id in the original response. Suddenly one day, the upstream abandoned this field and changed it to projectId, whose business meaning is consistent with the original id. If there is no anti-corrosion layer, then all places where this response is used must modify the code. And if there is an anti-corrosion layer, you can rewrite the getId method in the anti-corrosion response and return the projectId of the parent class, without any changes in the business code.

In addition, you can also define the structure you need by yourself, and use tools such as "mapStruct" to automatically convert data.

Pros and Cons of Corrosion
Writing an anti-corrosion layer also comes at a price. The biggest price is "additional development costs" . So if your upstream and downstream are relatively small and relatively stable, you can actually do without an anti-corrosion layer.

In large teams, it is valuable to pay these additional development costs, because the upstream and downstream relationships of large teams are very complicated. They may not be in the same team, and they may often perform iterative upgrades. From my own experience, interface changes It happens quite often.

Although we advocate not to modify the original interface, do not modify field names, method names, etc. But occasionally it is found that some things designed before are unreasonable and not conducive to long-term maintenance. If we design a v2 interface based on the new model and maintain the original v1 interface, the maintenance cost will increase. Therefore, the upstream that used the v1 interface is generally pushed to switch to v2, and then the v1 interface is offline. At this time, it is very important for the caller to have an anti-corrosion layer, which can reduce the cost of modification.