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

Figure 14.12. One context: deeper model
This second pass of model integration tends to slough off incidental or incorrect aspects of the
individual models and creates new concepts—in this case, "animal" with parts "trunk," "leg,"
"body," and "tail"—each of which has its own properties and clear relationships to other parts.
Successful model unification, to a large extent, hinges on minimalism. An elephant trunk is both
more and less than a snake, but the "less" is probably more important than the "more." Better to
lack the water-spewing ability than to have an incorrect poison-fang feature.
If the goal is simply to find the elephant, then translating between each model's expression of

---

location will do. When more integration is needed, the unified model doesn't have to reach full
maturity in the first version. It may be adequate for some needs to view an elephant as a wall,
held up by tree trunks, with a rope at one end and a snake at the other. Later, driven by new
requirements and by improved understanding and communication, the model can be deepened
and refined.
Recognizing multiple, clashing domain models is really just facing reality. By explicitly defining a
context within which each model applies, you can maintain the integrity of each and clearly see the
implications of any particular interface you want to create between the two. There is no way for
the blind men to see the whole elephant, but their problem would be manageable if only they
recognized the incompleteness of their perception.
[ Team LiB ]

---

[ Team LiB ]
Choosing Your Model Context Strategy
It is important always to draw the 
CONTEXT MAP
to reflect the current situation at any given time.
Once that's done, though, you may very well want to change that reality. Now you can begin to
consciously choose 
CONTEXT
boundaries and relationships. Here are some guidelines.