When doing refactoring in DDD, we must keep our focus in 3 key aspects:
- The domain;
- Look at thing in a different way;
- Continuous discussion with the domain experts.
Initiation
When do we refactor?
- Complex, confusing or awkward code is detected;
- Developers sense there’s a problem in the domain, like a missing concept or a wrong relation;
- Although the code is tidy, the domain code language is disconnected from the domain experts language;
- Developers gain knowledge about the domain and see possible improvements to the model
Exploration teams
After having found a trouble spot, we need to think of the improvement we need to make.
Figuring out how to solve the issue should come from knowledge crunching and brainstorming with colleague developers and domain experts alike, in meeting(s) up to 90min.
The decision on what to do, can come immediately after the first meeting or it can take a few meetings, maybe the group needs to sleep on it, maybe they need to build one, or several, proof of concepts.
Several different approaches can be used, as needed, but Eric Evans identifies 3 keys to keep this process focused and productive:
- Self-determination: A specific problem can be solved by a small team, assembled informally, specifically to solve this issue, after which it will be disbanded;
- Scope and sleep: Two or three short meetings, with a few days in between will produce the best results. If it is taking too much time, we probably need to break up the problem in smaller pieces;
- Exercising the UBIQUITOUS LANGUAGE: The knowledge crunching and brainstorming creates a good opportunity to exercise and improve the ubiquitous language. As a result, the developer should take those improvements and use them in the code.
Prior art
Base the refactoring on the prior work of others. Gather knowledge from domain literature (like accounting books, if the domain is accounting) and analysis patterns.
A design for developers
Software is for users, but also for developers. Developers have to build on top of already written code, which has been interactively refactored.
A supple design communicates its intent, it makes it easy to understand the code and reduces mental overload of developers.
Refactoring, both benefits from supple design and can lead to it.
Timing
The more we wait to make refactorings, the more costly they will be.
Needing to justify a refactoring, although it might seem to be reasonable, it severely hinders the developers capacity to refactor because such justification is not always explicitly evident.
Software development is not such a predictable process that the benefits of a change or the costs of not making a change can be accurately calculated.
Pg. 325
The time to refactor is when:
- The design does not express the team’s current understanding of the domain;
- Important concepts are implicit in the design (and you see a way to make them explicit);
- You see an opportunity to make some important part of the domain suppler.
Pg. 325
Crisis as opportunity
Refactoring is a continuous and steady process of refinement.
At some point there will be a breakthrough, the development team gains deeper insight on the domain and starts a deep and fast paced refactoring process, after which the steady refinement process restarts.
@hgraca 