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

Recognizing Splinters Within a B
OUNDED
 C
ONTEXT
Many symptoms may indicate unrecognized model differences. Some of the most obvious are
when coded interfaces don't match up. More subtly, unexpected behavior is a likely sign. The
CONTINUOUS INTEGRATION
process with automated tests can help catch these kinds of problems. But
the early warning is usually a confusion of language.
Combining elements of distinct models causes two categories of problems: 
duplicate concepts
and
false cognates
. Duplication of concepts means that there are two model elements (and attendant
implementations) that actually represent the same concept. Every time this information changes,
it has to be updated in two places with conversions. Every time new knowledge leads to a change
in one of the objects, the other has to be reanalyzed and changed too. Except the reanalysis
doesn't happen in reality, so the result is two versions of the same concept that follow different
rules and even have different data. On top of that, the team members must learn not one but two
ways of doing the same thing, along with all the ways they are being synchronized.
False cognates may be slightly less common, but more insidiously harmful. This is the case when
two people who are using the same term (or implemented object) think they are talking about the
same thing, but really are not. The example in the beginning of this chapter (two different
business activities both called 
Charge
) is typical, but conflicts can be even subtler when the two
definitions are actually related to the same aspect in the domain, but have been conceptualized in
slightly different ways. False cognates lead to development teams that step on each other's code,
databases that have weird contradictions, and confusion in communication within the team. The
term 
false cognate
is ordinarily applied to natural languages. For example, English speakers
learning Spanish often misuse the word 
embarazada
. This word does not mean "embarrassed"; it
means "pregnant." Oops.
When you detect these problems, your team will have to make a decision. You may want to pull
the model back together and refine the processes to prevent fragmentation. Or the fragmentation
may be a result of groups who want to pull the model in different directions for good reasons, and
you may decide to let them develop independently. Dealing with these issues is the subject of the
remaining patterns in this chapter.
[ Team LiB ]

---

[ Team LiB ]