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

Large-scale structure should be
applied when a structure can be found that greatly clarifies the system without forcing
unnatural constraints on model development. Because an ill-fitting structure is worse
than none, it is best not to shoot for comprehensiveness, but rather to find a minimal
set that solves the problems that have emerged. Less is more.
A large-scale structure can be very helpful and still have a few exceptions, but those exceptions
need to be flagged somehow, so that developers can assume the structure is being followed unless
otherwise noted. And if those exceptions start to get numerous, the structure needs to be changed
or discarded.
As mentioned, it is no mean feat to create a structure that gives the necessary freedom to
developers while still averting chaos. Although a lot of work has been done on technical
architecture for software systems, little has been published on the structuring of the domain layer.
Some approaches weaken the object-oriented paradigm, such as those that break down the
domain by application task or by use case. This whole area is still undeveloped. I've observed a
few general patterns of large-scale structures that have emerged on various projects. I'll discuss
four in this chapter. One of these may fit your needs or lead to ideas for a structure tailored to
your project.
[ Team LiB ]

---

[ Team LiB ]
System Metaphor
Metaphorical thinking is pervasive in software development, especially with models. But the
Extreme Programming practice of "metaphor" has come to mean a particular way of using a
metaphor to bring order to the development of a whole system.
Just as a firewall can save a building from a fire raging through neighboring buildings, a software
"firewall" protects the local network from the dangers of the larger networks outside. This
metaphor has influenced network architectures and shaped a whole product category. Multiple
competing firewalls—developed independently, understood to be somewhat interchangeable—are
available for consumers. Novices to networking readily grasp the concept. This shared
understanding throughout the industry and among customers is due in no small part to the
metaphor.
Yet it is an inexact analogy, and its power cuts both ways. The use of the firewall metaphor has led
to development of software barriers that are sometimes insufficiently selective and impede
desirable exchanges, while offering no protection against threats originating within the wall.
Wireless LANs, for example, are vulnerable. The clarity of the firewall has been a boon, but all
metaphors carry baggage.
[1]
[1]
S
YSTEM METAPHOR
finally made sense to me when I heard Ward Cunningham use this firewall example in a
workshop lecture.