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

Restructuring Yields Supple Design

---

Second, any change to the structure may lead to a lot of refactoring. The structure is evolving as
system complexity increases and understanding deepens. Each time the structure changes, 
the
entire system has to be changed to adhere to the new order.
Obviously that is a lot of work.
This isn't quite as bad as it sounds. I've observed that a design with a large-scale structure is
usually much easier to transform than one without. This seems to be true even when changing
from one kind of structure to another, say from 
METAPHOR
to 
LAYERS
. I can't entirely explain this.
Part of the answer is that it is easier to rearrange something when you can understand its current
arrangement, and the preexisting structure makes that easier. Partly it is that the discipline that it
took to maintain the earlier structure permeates all aspects of the system. But there is something
more, I think, because it is 
even easier
to change a system that has had 
two
previous structures.
A new leather jacket is stiff and uncomfortable, but after the first day of wear the elbows have
flexed a few times and are becoming easier to bend. After a few more wearings, the shoulders
have loosened up, and the jacket is easier to put on. After months of wear, the leather becomes
supple and is comfortable and easy to move in. So it seems to be with models that are
transformed repeatedly with sound transformations. Ever-increasing knowledge is embedded into
them and 
the principal axes of change have been identified and made flexible,
while stable aspects
have been simplified. The broader 
CONCEPTUAL CONTOURS
of the underlying domain are emerging in
the model structure.
Distillation Lightens the Load
Another crucial force that should be applied to the model is continuous distillation. This reduces the
difficulty of changing the structure in various ways. First, by removing mechanisms, 
GENERIC
SUBDOMAINS
, and other support structure from the 
CORE DOMAIN
, there may simply be less to
restructure.
If possible, these supporting elements should be defined to fit into the large-scale structure in a
simple way. For example, in a system of 
RESPONSIBILITY LAYERS
, a 
GENERIC SUBDOMAIN
could be
defined in such a way that it would fit within a single layer. With 
PLUGGABLE COMPONENTS
, a 
GENERIC
SUBDOMAIN
could be owned entirely by a single component, or it could be a 
SHARED KERNEL
among a
set of related components. These supporting elements may have to be refactored to find their
place in the structure; but they move independently of the 
CORE DOMAIN
, and tend to be more
narrowly focused, which makes it easier. And ultimately they are less critical, so refinement
matters less.
The principles of distillation and refactoring toward deeper insight apply even to the large-scale
structure itself. For example, the layers may initially be chosen based on a superficial
understanding of the domain; they are gradually replaced with deeper abstractions that express
the fundamental responsibilities of the system. This sharpedged clarity lets people see deep into
the design, which is the goal. It is also part of the means, as it makes manipulation of the system
on a large scale easier and safer.
[ Team LiB ]

---

[ Team LiB ]