I am the technical reviewer of The Chinese version of Clean Architecture, and I have some insights in the process of review, so I hope to share them with you by writing a guide.
Origin of the title
The Way of Clean Architecture is the Chinese translation of Clean Architecture. It may seem like a simple continuation of the Clean Code translation tradition, but in fact, we put a lot of effort into the Chinese name. When I got the first draft of the translation, the editor offered several alternative titles: “The Way of Architecture Simplicity”, “Architecture To the Clean” and “Clean Architecture”. These titles have their own considerations, and I can’t make a proper judgment without understanding the core ideas of the book. So after reading both the original and the translation, I started a proposal on the ThoughtWorks advisory group and had a great discussion. Finally, with the advice of my senior architect brother, the result was generally a neat architecture.
“The whole book talks about dependency governance,” shinge says. “If you reduce dependency complexity, it’s consistent with the idea of separating sub-domain hierarchies in DDD. Just as you organize your room and put things away, from this point of view, neat is better than simple, or clear.”
In addition, for the “architecture to clean” this candidate, the big devil’s attitude is not to clean, always feel dirty. Read between the lines. Yue Yue and XR, MBA students (XR says he didn’t get an MBA), start from the user’s mind, and believe that the Code Clean Way and the Architecture Clean Way can enhance each other’s memory and motivate users’ purchase behavior more easily.
Even when “clean architecture” is agreed upon, there is a different view of what “the way” is. Clean Code – A Handbook of Agile Software Craftsmanship, Clean Architecture – A Craftsman’s Guide to Software Structure and Design. We know that “Tao” is a metaphysical spiritual level. To be honest, the translation of “Tao” as Craftsman is a bit exaggerated.
Metaphysics is a metaphysical macroscopical category, using abstract (rational) thinking, the formless principles, which started in school, line in principle, and end in the tao, so there is a metaphysical way; The formless is a material aspect of the micro category, with a specific (emotional) thinking, the formless implements, which started in teaching, in law, or in art, so it is a formless thing.
One or the other? In fact, there are always trade-offs in everything, and it is often not too bad to follow the previous translation. Just like the principle of stable dependence summarized in Uncle Bob’s book, when we rely on a translation of more times, it will be more stable, such stability not to mention whether the formation of brand effect, SEO alone can save a lot of effort, so why not?
Uncle Bob’s writing is straightforward and easy to understand, and he especially likes to use examples from his own life. Moreover, there is no knowledge gap in this book, even the beginning programmer can complete the transformation of the knowledge of software architecture under uncle Bob’s guidance. Because he always starts from the most basic knowledge points, from the bottom up, step by step to build the shape of the architecture.
The essence of a paradigm is constraint
Programming paradigms are a topic of interest to programmers, like the long-running battle between Vim and Emacs editors. Their ups and downs are like treacherous rivers and lakes. Structured programming hero gradually fade out of the programmer’s field of vision, coveted for a long time object programming (OOP) to the thunder of the potential to dominate the martial arts, isolated corner of the functional programming (FP) endure for many years finally to wait for a chance. In 2012-2014, when OOP was being talked about, FP was like a programmer who wanted to shake things up. After the smoke, the eyes are not you die I die of the tragic situation, but you have me, I have you in the happy ending. The paradigm clash ended when Java, the conservative party of OOP, incorporated lambda expressions, a feature of FP.
Programmers talk about programming paradigms, and as a fan of FP, I’m no exception. But Uncle Bob argues that programming paradigms simply constrain the execution of programs and tell us what not to do.
- Structured programming is the standard and restriction of the direct transfer of program control
- Object – oriented programming is the standard and limitation of the indirect transfer of program control
- Functional programming is the specification and limitation of program assignment operations
Goto considered harmful
GotoConsideredHarmful
On the first day of learning C programming language, our teacher told us not to use goTO statement in the program, because goto would destroy the structure of the program. In the paper Go To Statement Considered Harmful, Dijkstra proved that the GOTO Statement prevented the recursive decomposition of large programs into smaller provable units, which meant that a large number of programs using goto statements could not be proved. Here, unprovable semantics are undecidable, similar to the liar’s paradox — the statement “I’m lying” cannot be proven and falsified, so not using goto is actually making small units of programming decidable. Unfortunately, Dijkstra did not prove procedural units, and the work was replaced by the scientific method of testing. On the premise of ensuring the decidability of program units, testing is a scientific method that can be falsified. The proposition “all crows are as black as black” can be falsified. We cannot enumerate all crows in the world. When we find a white crow one day, we can say that this proposition is false, which is falsified. Dijkstra says, “Testing can only prove the existence of a bug, not its absence.” It’s the same thing.
Testing ensures that the program unit is correct in the current known situation. Whenever a new test case causes a program unit to fail, we can fix the program to get it closer to the truth. This may be the beauty of TDD (Test Driven Development).
After removing the GOTO statement, we find that the computing process with the ability of order, loop and branch judgment is Turing complete, that is to say, the presence or absence of GOto does not affect the computing ability. Then goto’s role in the program can do more harm than good. In addition, the misuse of Goto can lead to a confusing structure for programmers, which should be avoided at all costs. So structured programming limits direct transfer of control over programs.
Pointer considered harmful
PointerConsideredHarmful
Everyone knows that object-oriented programming has three main characteristics: encapsulation, inheritance and polymorphism.
Encapsulation is to construct Abstract barriers to hide information. There is no lack of encapsulation in any programming paradigm, because it is a human need, a human way of simplifying the perception of a problem.
Inheritance is a way of reusing functions (procedures or apis). In the past, we wanted to use the same function on multiple structurally similar data, and needed to cast to the data type (structure Pointers) that the function could receive, which was always risky. In the object-oriented world, we no longer need to cast manually, but programming languages can do this automatically at run time by explicitly indicating inheritance relationships.
Polymorphism (polymorphism) is a kind of different special behavior associated with a single generalization mark ability, and the concept of polymorphic reference implementation – run which called dispatch code decisions, most of the dispatch based on type, type can also be based on the number of parameters and methods, and dispatch the concrete implementation process is dependent on a function pointer. When a function is declared as a single generalization notation, its concrete implementations can vary. With this notation, we actually decouple the declaration and implementation by finding the target function indirectly through the function pointer. So object-oriented programming limits the control over the indirect transfer of programs.
Mutability considered harmful
MutabilityConsideredHarmful
Neal Ford, in “Functional Thinking,” notes that object-oriented programming controls complexity by encapsulation of variables, while Functional programming controls complexity by eliminating variables. A remarkable feature of the function is immutability. Immutability means more memory consumption, worse performance? Not really. Functional programming languages based on the JVM, such as Scala and Clojure, make extensive use of persistence structures (e.g., Persistent Vector, see footnote 1) to implement immutable data structures without losing efficiency. Such data structures have huge advantages in highly concurrent environments, especially over critical sections and race conditions, which are often criticized in object-oriented programming.
Immutable data structures cannot be assigned repeatedly, so functional programming limits the operations that can be assigned to programs.
summary
Uncle Bob hit the nail on the head when he pointed out that most of what we’ve learned over the past 50 years is what not to do. This sets the tone for the book. Similarly, good architecture conveys the same message.
Why start with the programming paradigm? As I read through the entire book, IT dawned on me that Uncle Bob was actually conveying a design philosophy: top-down design is often unreliable in architectural design. Like the catalog in this book, from the basic building blocks of the program, to the components, and finally to the architecture, this process is very much in line with the characteristics of the system self-organization.
Why is top-down design often unreliable? Part 4 of this book, “Component Building Principles,” will have the answer, if needed, broken down next time.