The third part of the book starts in chapter 8 and talks about refactoring.
Refactoring towards deeper insight has the objective of having a domain model that closely reflects the domain. This makes the software more in tune with what the domain experts think and to the users current and future needs.
To successfully develop a model, we have three guidelines:
- Sophisticated domain models are achievable and worth the trouble;
- They can only be achieved through a continuous and iterative process of re-factoring;
- They may need high design skills to implement and to use.
The mentioned continuous refactoring includes refactoring at three different levels:
- Micro refactorings;
- Refactoring to patterns (Kerievsky 2003);
- Refactoring to a deeper model.
The goal of these refactorings is to transform the existing code, into code that, not only is easier to read and understand what it is doing, but also easy to relate to when communicating with the domain experts.
Breakthrough
Refactoring to a deeper model is referred by Eric Evans as “breakthrough”. A breakthrough happens when the team gains deeper insight into the domain, and realises there are deep design flaws that must be corrected, or otherwise maintain and grow a bloated system where it gets more and more difficult, and time consuming, to build new functionality and maintain the existing one.
When a prospect of a breakthrough is identified, it often involves the need for wide refactoring, which takes time and often means rebuilding already finished functionality. That is, of course, scary. However, although this type of refactoring involves much higher risk, its potential return is also much higher, as it allows for a real reflection of the domain, by the model, which has a high positive impact in the stability and maintainability of the project.
@hgraca 