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

When two development teams have an upstream/downstream relationship in which the
upstream has no motivation to provide for the downstream team's needs, the
downstream team is helpless. Altruism may motivate upstream developers to make
promises, but they are unlikely to be fulfilled. Belief in those good intentions leads the
downstream team to make plans based on features that will never be available. The
downstream project will be delayed until the team ultimately learns to live with what it
is given. An interface tailored to the needs of the downstream team is not in the cards.
In this situation, there are three possible paths. One is to abandon use of the upstream altogether.
This option should be evaluated realistically, making no assumptions that the upstream will
accommodate downstream needs. Sometimes we overestimate the value or underestimate the
cost of such a dependency. If the downstream team decides to cut the strings, they are going their
SEPARATE WAYS
(see the pattern description later in this chapter).
Sometimes the value of using the upstream software is so great that the dependency has to be

---

maintained (or a political decision has been made that the team cannot change). In this case, two
paths remain open; the choice depends on the quality and style of the up-stream design. If the
design is very difficult to work with, perhaps for lack of encapsulation, awkward abstractions, or
modeling in a paradigm the team cannot use, then the downstream team will still need to develop
its own model. They will have to take full responsibility for a translation layer that is likely to be
complex. (See 
ANTICORRUPTION LAYER
, later in this chapter.).
Following Isn't Always Bad
When using an off-the-shelf component that has a large interface, you should typically
CONFORM
to the model implicit in that component. Because the component and the
application are clearly different 
BOUNDED CONTEXTS
, based on team organization and
control, adapters may be needed for minor format changes, but the model should be
equivalent. Otherwise, you should question the value of having the component. If it is
good enough to give you value, there is probably knowledge crunched into its design.
Within its narrow sphere, it may well be much more advanced than your own
understanding. Your model presumably extends beyond the scope of this component,
and your own concepts will evolve for those other parts. But where they connect, your
model is a 
CONFORMIST
, following the lead of the component's model. In effect, you
could be dragged into a better design.
When your interface with a component is small, sharing a unified model is less
essential, and translation is a viable option. But when the interface is large and
integration is more significant, it usually makes sense to follow the leader.
On the other hand, if the quality is not so bad, and the style is reasonably compatible, then it may
be best to give up on an independent model altogether. This is the circumstance that calls for a
CONFORMIST
.
Therefore: