Domain-Driven Transformation

Part II. Technical, Tactical, and Team-Organizational Domain-Driven Transformation

Decomposing a legacy system with Domain-Driven Transformation is a major operation. Similar to a human before major surgery, you should make sure that the patient is in the best possible general health. How to do that is the topic of this second part of the book.

Most legacy systems we see are in poor general health—not only do they consist of one or more big ball(s) of mud, but they also suffer from the following problems:

• They have become rigid and inflexible and are difficult to change, and changes are very error prone due to the convoluted, difficult to understand structure.

• Overall, compared to systems with a good architecture, they have many undetected or even known errors, poor test coverage leading to the former, and many security gaps due to outdated libraries.

• They are difficult to build and deploy.

• They lack quality even at the level of simple code metrics, such as length of classes and methods, cycles between classes, number of parameters, etc.

If a legacy system is in such a distressed state, then we cannot immediately start with the strategic Domain-Driven Transformation (Part III). Rather, we must first improve the general condition of the legacy system to an appropriate level with appropriate measures that we describe in this second part of the book. In doing so, we will work on three levels to improve the general condition of our legacy system:

• Technical stabilization (see ...