Beyond Technologies: Domain Driven Design - Anticorruption layer

Introduction

In this post I sum up the most important concepts about Domain Driven Design.

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

Scenario

On a large project, one subsystem will often have to interface with several other, independently developed subsystems. These will reflect the problem domain differently. When systems based on different models are combined, the need for the system to adapt to the semantics of the other system can lead to a corruption of the new system’s own model.

We should create an isolating layer, ANTOCORRUPTION LAYER, to provide clients with functionality in terms of their own domain model. The layer talks to other system through its existing interface, requiring little or no modification to other system. Internally, the layer translates in both directions as necessary between the two models.

Note: ANTOCORRUPTION LAYER is not a mechanism for sending messages to another system, is a means of linking two BOUNDED CONTEXTS.

Designing the interface

The public interface of the ANTICORRUPTION LAYER usually appears as a set of SERVICES. Building a whole new layer responsible for the translation between the semantics of the two systems gives us an opportunity to reabstract the other system’s behavior and offer its services and information to our system consistently with our model.

Implementation

The ANTICORRUPTION LAYER is a combination of FAÇADES, ADAPTERS and translator, along with the communication and transport mechanisms needed to talk between systems.

A FAÇADE is an interface for a subsystem that simplifies access for the client and makes the subsystem easier to use. It should be written strictly in accordance with the other system’s model. The FAÇADE belongs in the BOUNDED CONTEXT of the other system. It just presents a friendlier face specialized for your needs.

An ADAPTER is a wrapper that allows a client to use a different protocol than that understood by the implementer of the behavior. When a client sends a message to an ADAPTER, it is converted to a semantically equivalent message and sent on to the “adaptee”. The response is converted and passed back.

For each SERVICE we define, we need an ADAPTER that supports the SERVICE’s interface and knows how to make equivalent requests of the other system or its FAÇADE.

The remaining element is the translator. The ADAPTER’s job is to know how to make a request. The actual conversion of conceptual objects or data is a distinct, complex task that can be placed in its own object, making them both much easier to understand. A translator can be a lightweight object that is instantiated when needed. It needs no state and does not need to be distributed, because it belongs with the ADAPTER it serves.

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.