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

Chapter Thirteen. Refactoring Toward
Deeper Insight
Refactoring toward deeper insight is a multifaceted process. It will be helpful to stop for a moment
to pull together the major points. There are three things you have to focus on.
Live in the domain.
1.
Keep looking at things a different way.
2.
Maintain an unbroken dialog with domain experts.
3.
Seeking insight into the domain creates a broader context for the process of refactoring.
The classic refactoring scenario involves a developer or two sitting at the keyboard, recognizing
that some code can be improved, and then changing it on the fly (with unit tests to verify their
results, of course). This practice should happen all the time, but it isn't the whole story.
The previous five chapters present an expanded view of refactoring, superimposed on the
conventional micro-refactoring approach.
[ Team LiB ]

---

[ Team LiB ]
Initiation
Refactoring toward deeper insight can begin in many ways. It may be a response to a problem in
the code—some complexity or awkwardness. Rather than apply a standard transformation of the
code, the developers sense that the root of the problem is in the domain model. Perhaps a concept
is missing. Maybe some relationship is wrong.
In a departure from the conventional view of refactoring, this same realization could come when
the code looks tidy, if the language of the model seems disconnected from the domain experts, or
if new requirements are not fitting in naturally. Refactoring might result from learning, as a
developer who has gained deeper understanding sees an opportunity for a more lucid or useful
model.
Seeing the trouble spot is often the hardest and most uncertain part. After that, developers can
systematically seek out the elements of a new model. They can brainstorm with colleagues and
domain experts. They can draw on systematized knowledge written as analysis patterns or design
patterns.
[ Team LiB ]

---

[ Team LiB ]