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

Chapter Ten. Supple Design
The ultimate purpose of software is to serve users. But first, that same software has to serve
developers. This is especially true in a process that emphasizes refactoring. As a program evolves,
developers will rearrange and rewrite every part. They will integrate the domain objects into the
application and with new domain objects. Even years later, maintenance programmers will be
changing and extending the code. People have to work with this stuff. But will they want to?
When software with complex behavior lacks a good design, it becomes hard to refactor or combine
elements. Duplication starts to appear as soon as a developer isn't confident of predicting the full
implications of a computation. Duplication is forced when design elements are monolithic, so that
the parts cannot be recombined. Classes and methods can be broken down for better reuse, but it
gets hard to keep track of what all the little parts do. When software doesn't have a clean design,
developers dread even looking at the existing mess, much less making a change that could
aggravate the tangle or break something through an unforeseen dependency. In any but the
smallest systems, this fragility places a ceiling on the richness of behavior it is feasible to build. It
stops refactoring and iterative refinement.
To have a project accelerate as development proceeds—rather than get weighed down by its own
legacy—demands a design that is a pleasure to work with, inviting to change. A supple design.
Supple design is the complement to deep modeling. Once you've dug out implicit concepts and
made them explicit, you have the raw material. Through the iterative cycle, you hammer that
material into a useful shape, cultivating a model that simply and clearly captures the key concerns,
and shaping a design that allows a client developer to really put that model to work. Development
of the design and code leads to insight that refines model concepts. Round and round—we're back
to the iterative cycle and refactoring toward deeper insight. But what kind of design are you trying
to arrive at? What kind of experiments should you try along the way? That is what this chapter is
about.

---

A lot of overengineering has been justified in the name of flexibility. But more often than not,
excessive layers of abstraction and indirection get in the way. Look at the design of software that
really empowers the people who handle it; you will usually see something simple. Simple is not
easy. To create elements that can be assembled into elaborate systems and still be
understandable, a dedication to 
MODEL-DRIVEN DESIGN
has to be joined with a moderately rigorous
design style. It may well require relatively sophisticated design skill to create 
or to use
.
Developers play two roles, each of which must be served by the design. The same person might
well play both roles—even switch back and forth in minutes—but the relationship to the code is
different nonetheless. One role is the developer of a client, who weaves the domain objects into
the application code or other domain layer code, utilizing capabilities of the design. A supple design
reveals a deep underlying model that makes its potential clear. The client developer can flexibly
use a minimal set of loosely coupled concepts to express a range of scenarios in the domain.
Design elements fit together in a natural way with a result that is predictable, clearly
characterized, and robust.
Equally important, the design must serve the developer working to change it. To be open to
change, a design must be easy to understand, revealing that 
same
underlying model that the
client developer is drawing on. It must follow the contours of a deep model of the domain, so most
changes bend the design at flexible points. The effects of its code must be transparently obvious,
so the consequences of a change will be easy to anticipate.
Early versions of a design are usually stiff. Many never acquire any suppleness in the time frame
or budget of the project. I've never seen a large program that had this quality throughout. But
when complexity is holding back progress, honing the most crucial, intricate parts to a supple
design makes the difference between getting sucked down into legacy maintenance and punching
through the complexity ceiling.
There is no formula for designing software like this, but I have culled a set of patterns that, in my
experience, tend to lend suppleness to a design when they fit. These patterns and examples
should give a feel for what a supple design is like and the kind of thinking that goes into it.