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

Chapter Twelve. Relating Design Patterns
to the Model
The patterns explored in this book so far are intended specifically for solving problems in a domain
model in the context of a 
MODEL-DRIVEN DESIGN
. Actually, though, most of the patterns published to
date are more technical in focus. What is the difference between a design pattern and a domain
pattern? For starters, the authors of the seminal book, 
Design Patterns
, had this to say:
Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern
can be another person's primitive building block. For this book we have concentrated on
patterns at a certain level of abstraction. Design patterns are not about designs such as
linked lists and hash tables that can be encoded in classes and reused as is. Nor are they
complex, domain-specific designs for an entire application or subsystem. The design patterns
in this book are descriptions of communicating objects and classes that are customized to
solve a general design problem in a particular context. [Gamma et al. 1995, p. 3]
Some, not all, of the patterns in 
Design Patterns
can be used as domain patterns. Doing so
requires a shift in emphasis. 
Design Patterns
presents a catalog of design elements that have
solved problems commonly encountered in a variety of contexts. The motivations of these patterns
and the patterns themselves are presented in purely technical terms. But a subset of these
elements can be applied in the broader context of domain modeling and design, because they
correspond to general concepts that emerge in many domains.
In addition to those in 
Design Patterns,
there have been many other technical design patterns
presented over the years. Some of them correspond to deep concepts that emerge in domains. It
would be nice to draw on this work. To make use of such patterns in domain-driven design, we
have to look at the patterns on two levels simultaneously. On one level, they are technical design
patterns in the code. On the other level, they are conceptual patterns in the model.
A sample of specific patterns from 
Design Patterns
will show how a pattern conceived as a design
pattern can be applied in the domain model, and it will clarify the distinction between a technical
design pattern and a domain pattern. 
COMPOSITE
and 
STRATEGY
demonstrate how some of the
classic design patterns can be applied to domain problems by thinking about them in a different
way. . . .
[ Team LiB ]

---

[ Team LiB ]