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

When a concrete analogy to the system emerges that captures the imagination of team
members and seems to lead thinking in a useful direction, adopt it as a large-scale
structure. Organize the design around this metaphor and absorb it into the 
UBIQUITOUS
LANGUAGE
. The 
SYSTEM METAPHOR
 should both facilitate communication about the system
and guide development of it. This increases consistency in different parts of the system,
potentially even across different 
BOUNDED CONTEXTS
. But because all metaphors are
inexact, continually reexamine the metaphor for overextension or inaptness, and be
ready to drop it if it gets in the way.
The "Naive Metaphor" and Why We Don't Need It
Because a useful metaphor doesn't present itself on most projects, some in the XP community
have come to talk of the 
naive metaphor
, by which they mean the domain model itself.
One trouble with this term is that a mature domain model is anything but naive. In fact, "payroll
processing is like an assembly line" is likely a much more naive view than a model that is the
product of many iterations of knowledge crunching with domain experts, and that has been proven
by being tightly woven into the implementation of a working application.
The term 
naive metaphor
should be retired.
S
YSTEM METAPHORS
are not useful on all projects. Large-scale structure in general is not essential.
In the 12 practices of Extreme Programming, the role of a 
SYSTEM METAPHOR
could be fulfilled by a
UBIQUITOUS LANGUAGE
. Projects should augment that 
LANGUAGE
with 
SYSTEM METAPHORS
or other
large-scale structures when they find one that fits well.
[ Team LiB ]

---

[ Team LiB ]