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

Software designs tend to be very abstract and hard to grasp. Developers and users
alike need tangible ways to understand the system and share a view of the system as a
whole.
On one level, metaphor runs so deeply in the way we think that it pervades every design. Systems
have "layers" that "lay on top" of each other. They have "kernels" at their "centers." But
sometimes a metaphor comes along that can convey the central theme of a whole design and
provide a shared understanding among all team members.
When this happens, the system is actually shaped by the metaphor. A developer will make design
decisions consistent with the system metaphor. This consistency will enable other developers to
interpret the many parts of a complex system in terms of the same metaphor. The developers and
experts have a reference point in discussions that may be more concrete than the model itself.
A 
SYSTEM METAPHOR
is a loose, easily understood, large-scale structure that it is harmonious with
the object paradigm. Because the 
SYSTEM METAPHOR
is only an analogy to the domain anyway,
different models can map to it in an approximate way, which allows it to be applied in multiple
BOUNDED CONTEXTS
, helping to coordinate work between them.
S
YSTEM METAPHOR
has become a popular approach because it is one of the core practices of
Extreme Programming (Beck 2000). Unfortunately, few projects have found really useful
METAPHORS
, and people have tried to push the idea into domains where it is counterproductive. A
persuasive metaphor introduces the risk that the design will take on aspects of the analogy that
are not desirable for the problem at hand, or that the analogy, while seductive, may not be apt.
That said, 
SYSTEM METAPHOR
is a well-known form of large-scale structure that is useful on some
projects, and it nicely illustrates the general concept of a structure.

---

Therefore: