My Book Notes: Clean Architecture by Robert C. Martin
I've recently read the book Clean Architecture by Uncle Bob. Firstly, I would like to say that I was impressed. The wording of the book is great. It shows the methodologies by telling stories and this technique amplifies my understanding of them. While I was reading the book, I took some careful and tidy notes. I am happy to share them with you.
I can start with this great phrase.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
The Consequences of not well-sturectured Architectures
The graphs below tell the whole story, I can’t say more.
Another phrase that I like
Dijkstra once said, “Testing shows the presence, not the absence, of bugs.” In other words, a program can be proven incorrect by a test, but it cannot be proven correct. All that tests can do, after sufficient testing effort, is allow us to deem a program to be correct enough for our purposes.
Component Cohesion
The Reuse/Release Equivalence Principle
Today's libraries are either third-party or written by us.
The Common Closure Principle
Single Responsibility Principle on the Component Level.
Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons
The Common Reuse Principle
Don’t force users of a component to depend on things they don’t need.
The Component Principles Graphs
Generally projects tend to start on the right side of the triangle. As the project matures, the project will slide over to the left.
Component Coupling
The Acyclic Dependencies Principle
For instance, you have three components whose names are A, B, C respectively. The component A depends on B, the component B depends on C. On the other hand, the component C depends on A. Thus you have a cyclic dependencies but you should not.
The dependency graph of packages must have no cycles.
Stable Dependency Principle
A component whose number of dependencies is less than the number of others depend on it is more stable.
The I Metric: Instability
This metric has the range [0,1]
For example, the I metric of Cc component is 1/4 = 0.25. 3 components depends on it and it depends on 1 component.
The SDP says that the I metric of a component should be larger than the I metrics of the components that it depends on. In this way, the I metric can decrease in the direction of dependency.
The I metric can be calculated with import statements in the languages.
The Stable Abstractions Principle
A component that is stable (I=0) should be abstract. Stable components that are extensible are flexible and do not overly constrain the architecture.
The A Metric: Abstractness
Nc: The number of classes in the component.
Na: The number of abstract classes and interfaces in the component
A: Abstractness = Na / Nc
The Zone of Pain: A component in this area is highly stable and concrete. Because of that it is rigid. It is not well-designed. They are not easy to change and extend. Examples are database schemas, utility library.
Non-volatile components can sit in this area, such as String library.
The Zone of Uselessness: They are forgotten abstract classes that implemented by no one.
The D Metric: Distance
D = |A + I — 1|
It has the range [0,1]. A value of 1 indicates that the component is as far away as possible from the Main Sequence.
The statistic science can be used here. Calculation variance of the D metric provides us the general information about the architecture. The calculation can be made for each release. Thereby the evolution of the software can be observed.
A good architect makes system easy to understand, easy to develop, easy to maintain and easy to deploy.
A good architect defers and delays which database will be used, which web server will be used, etc. He/She defers this decision until they will have to make.
A good architecture leaves options open. That means that you must able to separate components from the other ones easily.
Decoupling
Source Level
We can separate the code in source level. It means that separate into different classes or files or directories.
Deployment Level
The modules can lives under the same directory but they can be deployed to different servers.
Service Level
Microservices that are micro or not.
Screaming Architecture
The architecture of the system should tell you what it is for it. For instance; when you are looking at a e-commerce architecture, you should not see the framework details instead of the directories whose names are orders, customers etc.
Clean Architecture
Source code dependencies must point only inward, toward higher-level policies.
Nothing in an inner circle must not know about anything in an outer circle including class, functions and other software entities.
No name in an outer circle can be mentioned in an inner circle.
Entities
Entities are pure business rules. They have their own critical data and methods.
Use Cases
Use cases are business rules which are not as important as entities. They describe the behaviour of the application.
Frameworks
Frameworks are useful tools. But coupling your business rules to them very strictly can harm you in long-term. The commitment between you and the framework is one way. You make a long-term commitment to the framework, rather, the framework does not.
Code Structure by Packaging
The packaging type are Package by Layering, Package by Feature, Package by Domain (DDD), Package by Component respectively.
Conclusion
That’s all. Thank you for reading. I strongly recommend you to read this book after have experience about 2 years in the industry.
