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

Open Host Service 
 Published Language
You have been integrating with other systems with a series of ad hoc protocols, but the
maintenance burden is mounting as more systems want access, or perhaps the interaction is
becoming very difficult to understand. You need to formalize the relationship between the systems
with a 
PUBLISHED LANGUAGE
.
If an industry-standard language is available, evaluate it and use it if at all possible.
1.
If no standard or prepublished language is available, then begin by sharpening up the 
CORE
DOMAIN
of the system that will serve as the host. (See Chapter 15.)
2.
Use the 
CORE DOMAIN
as the basis of an interchange language, using a standard interchange
paradigm such as XML, if at all possible.
3.
Publish the new language to all involved in the collaboration (at least).
4.
If a new system architecture is involved, publish that too.
5.
Build translation layers for each collaborating system.
6.
Switch over.
7.
At this point, additional collaborators should be able to enter with minimal disruption.
Remember, the 
PUBLISHED LANGUAGE
must be stable, yet you'll still need the freedom to change the
host's model as you continue your relentless refactoring. Therefore, 
do not equate the interchange
language and the model of the host.
Keeping them close together will reduce translation overhead,
and you may choose to make your host a 
CONFORMIST
. But reserve the right to beef up the
translation layer and diverge if the cost-benefit trade-off favors that.
Project leaders should define 
BOUNDED CONTEXTS
based on functional integration requirements and
relationships of development teams. Once 
BOUNDED CONTEXTS
and a 
CONTEXT MAP
are explicitly

---

defined and respected, then logical consistency should be protected. Related communication
problems will at least be exposed so they can be dealt with.
However, sometimes model contexts, whether consciously bounded or naturally occurring, are
misapplied to solve problems other than logical inconsistency within a system. The team may find
that the model of a large 
CONTEXT
seems too complex to comprehend as a whole, or to analyze
completely. By choice or by chance, this often leads to breaking down the 
CONTEXTS
into more
manageable pieces. This fragmentation leads to lost opportunities. Now, it is worth scrutinizing a
decision to establish a large model in a broad 
CONTEXT
, and if it is not organizationally or politically
possible to keep together, if it is in reality fragmenting, then redraw the map and define
boundaries you can keep. But if a large 
BOUNDED CONTEXT
addresses compelling integration needs,
and if it seems feasible apart from the complexity of the model itself, then breaking up the
CONTEXT
may not be the best answer.
There are other means of making large models tractable that should be considered before making
this sacrifice. The next two chapters focus on managing complexity within a big model by applying
two more broad principles: distillation and large-scale structure.
[ Team LiB ]

---

[ Team LiB ]