DDD serialized article
I think that there are various discussions about the good and bad of design every day, but is there a clear definition of "good design" and "bad design"? Although it is vague or fragmentary in each head, it seems that the team does not often define good or bad.
I think it's worth discussing in each project, but I think it's easier to discuss if there is one standard. So let's take a look at one of the definitions of "bad design" proposed by Robert Cecil Martin, aka Uncle Bob, who advocated the principle of object orientation.
Before that, I would like to introduce Uncle Bob.
Robert Cecil Martin(wikipedia)
The author of the famous "clean code" is easy to understand. In addition, he is an advocate of the SOLID principle, which is an object-oriented design principle, and a co-author of the Agile Software Development Declaration. , The impact on the software industry is immeasurable.
(As an aside, I introduced it in What is the easiest architecture to get started with Domain Driven Design This is also the proponent of the application architecture "Clean Architecture". The site that is operated is also called Clean Coder, and we are particular about the name clean. It seems that there is. It seems that it was from here when I wondered where the "clean" of the clean architecture came from.)
The original text referenced this time is further in the page of The Principles of OOD of Old UncleBob Site. , Article of The Dependency Inversion Principle. This is a quote and summary of the contents.
A design that has the following three properties that all engineers can agree on is called a "bad design".
- Rigidity :
It is hard to change because every change affects too many other parts of the system.
Translate it into Japanese, and then write a partial translation and summary of the details described after that.
Difficult to change, as each change affects many other parts of the system.
The cause is that you have to make a chain of modifications to the dependent modules for one change.
If the designer cannot predict the extent to which modifications need to be made, the impact and cost will be unpredictable. Authorities then dislike approving changes, which puts rigid pressure on them.
Countermeasures You may have said "reduce the number of dependent modules" and "make the dependent modules logically inferrable".
A contrasting property is Flexibility.
Making changes breaks unexpected parts of the system.
Often, changes can create new problems in areas that are not conceptually relevant. This causes the maintenance team to become less reliable. The more development you continue, the more troubles that appear to be irrelevant occur, and each time you make a correction, another trouble occurs ... and the man-hours required for maintenance continue to increase.
As a countermeasure, you can think of saying "make it depend only on modules that are conceptually related" and "make it within the range where the dependent modules can be logically guessed" as in 1.
A contrasting property is Robustness.
Strongly coupled with the current application, making it difficult to reuse in another application.
If part of an implementation relies heavily on something that is business-specific, then the reusability of that implementation is low. When designers investigate the reuse of implementations, they find that there is a lot of work required to separate and reuse modules, and in many cases they give up on reuse.
Is the countermeasure "increasing the cohesion of the module"?
A contrasting property is Reusability.
What do you think. It may be easier to imagine by thinking "the definition of bad design, inside out" rather than "definition of good design".
Also, based on this, it may be used as a basis for reconsidering your own thoughts and team policies.
Recommended Posts