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

Catering to Special Needs with Distinct Models
Different groups within the same business have often developed their own specialized
terminologies, which may have diverged from one another. These local jargons may be very

---

precise and tailored to their needs. Changing them (for example, by imposing a standardized,
enterprise-wide terminology) requires extensive training and analysis to resolve the differences.
Even then, the new terminology may not serve as well as the finely tuned version they already
had.
You may decide to cater to these special needs in separate 
BOUNDED CONTEXTS
, allowing the
models to go 
SEPARATE WAYS
, except for 
CONTINUOUS INTEGRATION
of translation layers. Different
dialects of the 
UBIQUITOUS LANGUAGE
will evolve around these models and the specialized jargon
they are based on. If the two dialects have a lot of overlap, a 
SHARED KERNEL
may provide the
needed specialization while minimizing the translation cost.
Where integration is not needed, or is relatively limited, this allows continued use of customary
terminology and avoids corruption of the models. It also has its costs and risks.
The loss of shared language will reduce communication.
There is extra overhead in integration.
There will be some duplication of effort, as different models of the same business activities
and entities evolve.
But perhaps the biggest risk is that it can become an argument against change and a justification
for any quirky, parochial model. How much do you need to tailor this individual part of the system
to meet specialized needs? Most important, 
how valuable is the particular jargon of this user
group
? You have to weigh the value of more in-dependent action of teams against the risks of
translation, keeping an eye out for rationalizing terminology variations that have no value.
Sometimes a deep model emerges that can unify these distinct languages and satisfy both groups.
The catch is that deep models emerge later in the life cycle, after a lot of development and
knowledge crunching, if at all. You can't plan on a deep model; you just have to accept the
opportunity when it arises, change your strategy, and refactor.
Keep in mind that, where integration requirements are extensive, the cost of translation goes way
up. Some coordination of the teams, from the pinpoint modifications of one object that has a
complicated translation ranging up to a 
SHARED KERNEL
, can make translation easier while still not
requiring full unification.