Domain-Driven Design: Tackling Complexity in the Heart of Software

Create an isolating layer to provide clients with functionality in terms of their own
domain model. The layer talks to the other system through its existing interface,
requiring little or no modification to the other system. Internally, the layer translates in
both directions as necessary between the two models.
This discussion of a mechanism to link two systems might bring to mind issues of transporting the
data from one program to another or from one server to another. I'll discuss the incorporation of
the technical communications mechanism shortly. But such details shouldn't be confused with an
ANTICORRUPTION LAYER
, which is not a mechanism for sending messages to another system. Rather,
it is a mechanism that translates conceptual objects and actions from one model and protocol to
another.
An 
ANTICORRUPTION LAYER
can become a complex piece of software in its own right. Next I'll outline
some of the design considerations for creating one.
Designing the Interface of the A
NTICORRUPTION
 L
AYER
The public interface of the 
ANTICORRUPTION LAYER
usually appears as a set of 
SERVICES
, although
occasionally it can take the form of an 
ENTITY
. 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. It may not even make sense, in our model, to represent the external system as a single
component. It may be best to use multiple 
SERVICES
(or occasionally 
ENTITIES
), each of which has a
coherent responsibility in terms of our model.
Implementing the A
NTICORRUPTION
 L
AYER
One way of organizing the design of the 
ANTICORRUPTION LAYER
is as a combination of 
FACADES
,
ADAPTERS
(both from Gamma et al. 1995), and translators, along with the communication and
transport mechanisms usually needed to talk between systems.
We often have to integrate with systems that have large, complicated, messy interfaces. This is an
implementation issue, not an issue of conceptual model differences that motivated the use of
ANTICORRUPTION LAYERS
, but it is a problem you'll encounter trying to create them. Translating from
one model to another (especially if one model is fuzzy) is a hard enough job without
simultaneously dealing with a subsystem interface that is hard to talk to. Fortunately, that is what
FACADES
are for.
A 
FACADE
is an alternative interface for a subsystem that simplifies access for the client and makes

---

the subsystem easier to use. Because we know exactly what functionality of the other system we
want to use, we can create a 
FACADE
that facilitates and streamlines access to those features and
hides the rest. The 
FACADE
does 
not
change the model of the underlying system. It should be
written strictly in accordance with the other system's model. Otherwise, you will at best diffuse
responsibility for translation into multiple objects and overload the 
FACADE
and at worst end up
creating yet another model, one that doesn't belong to the other system 
or
your own 
BOUNDED
CONTEXT
. The 
FACADE
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. I'm using the term 
adapter
a little loosely, because the emphasis in Gamma et al.
1995 is on making a wrapped object conform to a standard interface that clients expect, whereas
we get to choose the adapted interface, and the adaptee is probably not even an object. Our
emphasis is on translation between two models, but I think this is consistent with the intent of
ADAPTER
.
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 
FACADE
.
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(S)
it serves.
Those are the basic elements I use to create an 
ANTICORRUPTION LAYER
. There are a few other
considerations.
Typically, the system under design (your subsystem) will be initiating action, as implied by
Figure 14.8. There are cases, however, when the other subsystem may need to request
something of your subsystem or notify it of some event. An 
ANTICORRUPTION LAYER
can be
bidirectional, defining 
SERVICES
on both interfaces with their own 
ADAPTERS
, potentially using
the same translators with symmetrical translations. Although implementing the
ANTICORRUPTION LAYER
doesn't usually require any change to the other subsystem, it might be
necessary in order to make the other system call on 
SERVICES
of the 
ANTICORRUPTION LAYER
.