Part 4

Personal takeways from "Robert C. Martin - Clean Architecture" Part 4

Components

p96 - "Components are the units of deployment. (...) In all languages, they are the granule of deployment."

p96 - "Regardless of how they are eventually deployed, welll designed components always retain the ability to be independently deployable and, therefore, independently developable."

p101 - Murphy's law of program size - "Programs will grow to fill all available compile and link time."

The Reuse/Release Equivalence Principle

p104 - "The granule of reuse is the granule of release."

p105 - "From a software design and architecture point of view, this principle means that the classes and modules that are formed into a component must belong to a cohesive group."

p105 - "Classes and modules that are grouped together into a component should be releasable together."

The Common Closure Principle

p105 - "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. (...) p106 - This is the Single Responsability Principle restated for components."

p105 - "The CCP prompts us to gather in one place all the classes that are likely to change for the same reasons. (...) This principle is closely associated with the Open Closed Principle. (...) We design our classes such that they are closed to the most common kinds of changes that we expect or have experienced."

p107 - "Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons."

The Common Reuse Principle

p107 - "Don't force users of a component to depend on things they don't need."

p107 - "The CRP is the generic version of the ISP. The ISP advises us not to depend on classes that have methods we don't use. The CRP advises us not to depend on components that have classes we don't use."

Component Coupling

p107 - "The forces that impinge upon the architecture of a component structure are technical, political and volatile."

The Acyclic Dependencies Principle

p112 - "Allow no cycles in the component dependency graph."

The Stable Dependencies Principle

p120 - "Depend in the direction of stability."

p120 - "Any component that we expect to be volatile should not depend on by a component that is difficult to change. Otherwise, the volatile component will also be difficult to change."

Stability

p120 - "Stability is related to the amount of work required to make a change."

p121 - "One sure way to make a software component difficult to change, is to make lots of other software components depend on it."

p121 - "I: Instability: I = Fan-out / (Fan-in + Fan-out). This metric has the range [0,1]. I = 0 indicates a maximally stable component. I = 1 indicated a maximally unstable component."

p121 - "The SDP says that the I metric of a component should be larger than the I metrics of the components that it depends on. That is, I metrics should decrease in the direction of dependency."

The Stable Abstractions Principle

p126 - "A component should be as abstract as it is stable."

p127 - "The SAP and the SDP combined amount to the DIP for components. This is true because the SDP says that dependencies should run in the direction of stability, and te SAP says that stability implies abstraction. Thus dependencies run in the direction of abstraction."

The Main Sequence

p130 - "D: Distance. D = |A+I-1|"