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

Prior Art
It isn't always necessary to reinvent the wheel. The process of brain-storming for missing concepts
and better models has a great capacity to absorb ideas from any source, combine them with local
knowledge, and continue crunching to find answers to the current situation.
You can get ideas from books and other sources of knowledge about the domain itself. Although
the people in the field may not have created a model suitable for running software, they may well
have organized the concepts and found some useful abstractions. Feeding the knowledge-
crunching process this way leads to richer, quicker results that also will probably seem more
familiar to domain experts.
Sometimes you can draw on the experience of others in the form of analysis patterns. This kind of
input has some of the effect of reading about the domain, but in this case it is geared specifically
toward software development, and it should be based directly on experience implementing
software in your domain. Analysis patterns can give you subtle model concepts and help you avoid
lots of mistakes. But they don't give you a cookbook recipe. They feed the knowledge-crunching
process.
As the pieces are fit together, model concerns and design concerns must be dealt with in parallel.
Again, it doesn't always mean inventing everything from scratch. Design patterns can often be
employed in the domain layer when they fit both an implementation need and the model concept.
Likewise, when a common formalism, such as arithmetic or predicate logic, fits some part of a
domain, you can factor that part out and adapt the rules of the formal system. This provides very
tight and readily understood models.
[ Team LiB ]

---

[ Team LiB ]
A Design for Developers
Software isn't just for users. It's also for developers. Developers have to integrate code with other
parts of the system. In an iterative process, developers change the code again and again.
Refactoring toward deeper insight both leads to and benefits from a supple design.
A supple design communicates its intent. The design makes it easy to anticipate the effect of
running code—and therefore it easy to anticipate the consequences of changing it. A supple design
helps limit mental overload, primarily by reducing dependencies and side effects. It is based on a
deep model of the domain that is fine-grained only where most critical to the users. This makes for
flexibility where change is most common, and simplicity elsewhere.
[ Team LiB ]

---

[ Team LiB ]
Timing
If you wait until you can make a complete justification for a change, you've waited too long.
Your
project is already incurring heavy costs, and the postponed changes will be harder to make
because the target code will have been more elaborated and more embedded in other code.
Continuous refactoring has come to be considered a "best practice," but most project teams are
still too cautious about it. They see the risk of changing code and the cost of developer time to
make a change; but what's harder to see is the risk of keeping an awkward design and the cost of
working around that design. Developers who want to refactor are often asked to justify the
decision. Although this seems reasonable, it makes an already difficult thing impossibly difficult,
and tends to squelch refactoring (or drive it underground). Software development is not such a
predictable process that the benefits of a change or the costs of not making a change can be
accurately calculated.
Refactoring toward deeper insight needs to become part of the ongoing exploration of the subject
matter of the domain, the education of the developers, and the meeting of the minds of
developers and domain experts. Therefore, refactor when
The design does not express the team's current understanding of the domain;
Important concepts are implicit in the design (and you see a way to make them explicit); or
You see an opportunity to make some important part of the design suppler.
This aggressive attitude does not justify any change at any time. Don't refactor the day before a
release. Don't introduce "supple designs" that are just demonstrations of technical virtuosity but
fail to cut to the core of the domain. Don't introduce a "deeper model" that you couldn't convince a
domain expert to use, no matter how elegant it seems. Don't be absolute about things, but push
beyond the comfort zone in the direction of favoring refactoring.
[ Team LiB ]

---

[ Team LiB ]