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

Eliminate the complexity of translation between 
BOUNDED CONTEXTS
 by slavishly
adhering to the model of the upstream team. Although this cramps the style of the
downstream designers and probably does not yield the ideal model for the application,
choosing 
CONFORMITY
 enormously simplifies integration. Also, you will share a
UBIQUITOUS LANGUAGE
 with your supplier team. The supplier is in the driver's seat, so it
is good to make communication easy for them. Altruism may be sufficient to get them
to share information with you.
This decision deepens your dependency on the upstream and limits your application to the
capabilities of the upstream model— plus purely additive enhancements. It is very unappealing
emotionally, which is why we choose it less often than we probably should.
If these trade-offs are not acceptable, but the upstream dependency is indispensable, the second
option still remains: Insulate yourself as much as possible by creating an 
ANTICORRUPTION LAYER
, an
aggressive approach to implementing a translation map that will be discussed later.
C
ONFORMIST
resembles 
SHARED KERNEL
in that both have an overlapping area where the model is
the same, areas where your model has been extended by addition, and areas where the other
model does not affect you. The difference between the patterns is in the decision-making and
development processes. Where the 
SHARED KERNEL
is a collaboration between two teams that
coordinate tightly, 
CONFORMIST
deals with integration with a team that is not interested in

---

collaboration.
We've been proceeding down a spectrum of cooperation in the integration between 
BOUNDED
CONTEXTS
, from highly cooperative 
SHARED KERNELS
or 
CUSTOMER/SUPPLIER DEVELOPER TEAMS
to the
one-sidedness of the 
CONFORMIST
. Now we'll take the final step to an even more pessimistic view of
the relationship, assuming neither cooperation nor a usable design on the other side. . . .
[ Team LiB ]

---

[ Team LiB ]