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

Appendix The Use of Patterns in This
Book
My first "nice car," which I was given shortly after college, was an eight-year-old Peugeot.
Sometimes called the "French Mercedes," this car was well crafted, was a pleasure to drive, and
had been very reliable. But by the time I got it, it was reaching the age when things start to go
wrong and more maintenance is required.
Peugeot is an old company, and it has followed its own evolutionary path over many decades. It
has its own mechanical terminology, and its designs are idiosyncratic; even the breakdown of
functions into parts is sometimes nonstandard. The result is a car that only Peugeot specialists can
work on, a potential problem for someone on a grad student income.
On one typical occasion, I took the car to a local mechanic to investigate a fluid leak. He examined
the undercarriage and told me that oil was "leaking from a little box about two-thirds of the way
back that seems to have something to do with distributing braking power between front and rear."
He then refused to touch the car and advised me to go to the dealership, fifty miles away. Anyone
can work on a Ford or a Honda; that's why those cars are more convenient and less expensive to
own, even though they are equally mechanically complex.
I did love that car, but I will never own a quirky car again. A day came when a particularly
expensive problem was diagnosed, and I had had enough of Peugeots. I took it to a local charity
that accepted cars as donations. Then I bought a beat-up old Honda Civic for about what the
repair would have cost.
Standard design elements are lacking for domain development, and so every domain model and
corresponding implementation is quirky and hard to understand. Moreover, every team has to
reinvent the wheel (or the gear, or the windshield wiper). In the world of object-oriented design,
everything is an object, a reference, or a message—which, of course, is a useful abstraction. But
that does not sufficiently constrain the range of domain design choices and does not support an
economical discussion of a domain model.
To stop with "Everything is an object" would be like a carpenter or an architect summing up
houses by saying "Everything is a room." There would be the big room with high-voltage outlets
and a sink, where you might cook. There would be the small room upstairs, where you might
sleep. It would take pages to describe an ordinary house. People who build or use houses realize
that rooms follow patterns, patterns with special names, such as "kitchen." This language enables
economical discussion of house design.
Moreover, not all combinations of functions turn out to be practical. Why not a room where you
bathe and sleep? Wouldn't that be convenient. But long experience has precipitated into custom,
and we separate our "bedrooms" from our "bathrooms." After all, bathing facilities tend to be
shared among more people than bedrooms are, and they require maximum privacy, even from the
others who share the same bedroom. And bathrooms have specialized and expensive
infrastructure requirements. Bathtubs and toilets typically end up in the same room because both
require the same infrastructure (water and drainage) and both are used in private.
Another room that has special infrastructure requirements is that room where you might prepare
meals, also known as the "kitchen." In contrast to the bathroom, a kitchen has no special privacy
requirements. Because of its expense, there is typically only one, even in relatively large houses.

---

This singularity also facilitates our communal food preparation and eating customs.
When I say that I want a three-bedroom, two-bath house with an open-plan kitchen, I have
packed a huge amount of information into a short sentence, and I've avoided a lot of silly
mistakes—such as putting a toilet next to the refrigerator.
In every area of design—houses, cars, rowboats, or software—we build on patterns that have been
found to work in the past, improvising within established themes. Sometimes we have to invent
something completely new. But by basing standard elements on patterns, we avoid wasting our
energy on problems with known solutions so that we can focus on our unusual needs. Also,
building from conventional patterns helps us avoid a design so idiosyncratic that it is difficult to
communicate.
Although software domain design is not as mature as other design fields—and in any case may be
too diverse to accommodate patterns as specific as those used for car parts or rooms—there is
nonetheless a need to move beyond "Everything is an object" to at least the equivalent of
distinguishing bolts from springs.
A form for sharing and standardizing design insight was introduced in the 1970s by a group of
architects led by Christopher Alexander (Alexander et al. 1977). Their "pattern language" wove
together tried-and-true design solutions to common problems (much more subtly than my
"kitchen" example, which has probably caused some readers of Alexander to cringe). The intent
was that builders and users would communicate in this language, and they would be guided by the
patterns to produce beautiful buildings that worked well and felt good to the people who used
them.
Whatever architects might think of the idea, this pattern language has had a big impact on
software design. In the 1990s software patterns were applied in many ways with some success,
notably in detailed design (Gamma et al. 1995) and technical architectures (Buschmann et al.
1996). More recently, patterns have been used to document basic object-oriented design
techniques (Larman 1998) and enterprise architectures (Fowler 2002, Alur et al. 2001). The
language of patterns is now a mainstream technique for organizing software design ideas.
The pattern names are meant to become terms in the language of the team, and I've used them
that way in this book. When a pattern name appears in a discussion, it is 
FORMATTED IN SMALL CAPS
to call it out.
Here is how I've formatted patterns in this book. There is some variation around this basic plan, as
I have favored case-by-case clarity and readability over rigid structure. . . .
[ Team LiB ]

---

[ Team LiB ]