I have been reading the book "Clean Architecture" recently. The book's explanation of software design and architecture is very profound. So I opened a column to record some excellent architectural design concepts in the book "Clean Architecture" and my thoughts on these contents.
1. What is a component
A component is the deployment unit of software, and is the smallest entity that can independently complete the deployment of the entire software system during the deployment process. Multiple components can be assembled into a single executable.
Such as jar files in Java, DLL files in .Net.
Murphy's Law of program size:
The program size will continue to grow until the limited compilation and linking time is filled.
2. The principle of component aggregation
REP: Reuse and release equivalence principle
The minimum granularity of component reuse is equal to the minimum granularity of its release.
This is a very well-understood principle. After all, if you want to reuse a certain component, you must use a certain version released by the component.
After all, only when the version is introduced can the user know when the component is released and the changes brought about by each release. After that, users can decide whether to continue using the old version or upgrade based on the updated content released.
CCP: Common Closure Principle
We should put classes that will be modified at the same time and for the same purpose into the same component.
This is actually a description of the single responsibility principle at the component level. For most applications, maintainability is far more important than reusability. If we have to make changes to some code, they'd better be in the same component. In this way, only the component needs to be operated during testing and deployment.
CRP: Common Reuse Principle
Don't force users of a component to depend on things they don't need.
The role of CRP is not only to tell us which modules should be put together, but more importantly which modules should be separated. Because whenever a component references another component, a dependency relationship will be added, and when the referenced component changes, the component that references it must also be changed accordingly, which may consume a lot of energy to do unnecessary component deployment.
3. The principle of component coupling
1. There should be no circular dependencies between components, and a reasonable component coupling structure should be a directed acyclic graph.
2. The dependency relationship must point to a more stable direction. In other words, the more frequently modified components are, the more you need to rely on those relatively stable components.
And dependencies like the following will make it very difficult to change Flexible components.
It is also true that the stability of a component should be consistent with its level of abstraction, that is to say, the more stable a component is, the higher its level of abstraction should be.
4. Standards for measuring the stability and abstraction of components
For the stability and abstraction of components, we can use the IA diagram to measure, I is stability, the higher the value, the lower the stability. A is the degree of abstraction, 0 means no abstract class, 1 means only abstract class.
That is, the most stable component, which contains all abstract classes, should be in the upper left corner, and the least stable, most specific component, should be in the lower right corner.
The two areas drawn in the figure - "Pain Zone" and "Useless Zone" are the areas that must be avoided when designing components.
Components in the pain zone will have high stability and very specific logic implementation, which means that the components are difficult to modify and expand, which is not a good design.
Components in the useless area will have a very low stability and very abstract logic implementation, which means that this component basically has no other components to depend on it, but its logic is still very abstract, and this kind of component cannot be used at all. .