DDD: Breakthrough

Martin Fowler made the term refactoring popular. His book Refactoring: Improving the Design of Existing Code offers micro-refactorings that help reduce the stench of the code smells in the code. These micro-refactorings can usually be automated as exemplified by increase of automated refactorings in popular IDEs. Taking it up a notch is the concept of Refactoring to Patterns introduced by Joshua Kerievsky in a book of similar title. Refactoring to Patterns describes the process of modifying existing code to embody established design patterns. I am halfway through that book and it does offer good linkage between design patterns and refactoring.

Nonetheless, Evans wants to "kick it up a notch" (to quote TV's celebrity chef). The refactorings he wants to achieve not only make the code more readable, but it is also offers the "aha" feeling to the design when it is done right. This is the breakthrough. At this point, not only is code being affect, the entire model might be affected as well. This is a change that will ripple through the entire system. Thus, it is a costly change that can take weeks (not hours or even minutes like the micro-refactorings). But, with its cost, comes greater insight into the design and model more suited to address future requirements (or handle existing one better).

Figure 1: Returns from refactorings are not linear

This chapter presents the motivation for refactoring the domain. While this chapter ended with a happy ending, I will not be surprised if some refactorings had dire consequences instead of beneficial ones. Nonetheless, those dire consequences will open up new insights that can be used in a future iteration.