Book Review Series - Clean Architecture

Source

『Clean Architecture』 Robert C. Martin / Junyi Song (trans.) | Insight | August 2019

One-line review

A book that becomes a mentor when you think about good design

Summary of Clean Architecture

What is architecture?

Architecture and design are sometimes interpreted in this way when they are distinguished.

• Architecture: Used to refer to something high-level that is separated from low-level details
• Design: Often means low-level structures or decisions

But in reality, there is no clear boundary between them. There is only a continuity of decision-making from high-level to low-level.

Low-level details and high-level structures are all components of the overall software design.

The goal of software architecture is to minimize the manpower required to create and maintain the system.

The measure of design quality is good design if the cost is low and can be kept low until the end of the system's life.

Behavior and structure

• Behavior: Implementing functional specifications or requirements, and fixing bugs
• Structure: Making it easy and simple to apply changes when you change your mind about functionality

Focusing on only one of behavior and structure results in short-lived software.

Programming paradigms

Paradigms tell you what not to do rather than what to do.

• Structured programming: Imposes rules on direct transitions of control flow
  • 1968, Edsger W. Dijkstra
  • Indiscriminate goto is harmful. Replace with if/then/else, do/while/until
• Object-oriented programming: Imposes rules on indirect transitions of control flow
  • 1966, Ole-Johan Dahl, Kristen Nygaard. ALGOL language
  • They discovered that local variables declared in a function could last a long time after the function call returned by moving the function call stack frame to the heap. This function became the class constructor, the local variable became the instance variable, and the nested function became the method.
• Functional programming: Imposes rules on assignment statements
  • 1958, John McCarthy. LISP language
  • The concept that underlies the LIST language is lambda calculus.
  • The concept that underlies lambda calculus is immutability, which means that the value of a symbol does not change.
  • This means that there are no assignment statements in functional languages. (They are provided, but very tricky.)

SOLID principles

They started collecting these principles while discussing software design principles with many people. The final version came out as a result of replacing/changing/deleting/merging the principles.

• SRP: Single Responsibility Principle
  • The optimal structure of a software system is greatly influenced by the social structure of the organization that creates the system. Therefore, each software module must have only one reason for change.
• OCP: Open-Closed Principle
  • In order to change the behavior of the system, the software system must be designed so that new code can be added instead of modifying existing code.
• LSP: Liskov Substitution Principle
  • Liskov's famous principle on subtypes
  • In order to create a software system using interchangeable components, these components must always adhere to the contract that they must be interchangeable with each other.
• ISP: Interface Segregation Principle
  • Do not depend on what you do not use.
• DIP: Dependency Inversion Principle
  • Code that implements high-level policies must never depend on code that implements low-level details. Instead, the details should depend on the policy.

Component cohesion principles

• REP: Reuse/Release Equivalence Principle
  • The unit of reuse is the same as the unit of release.
• CCP: Common Closure Principle
  • Group classes that change for the same reason and at the same time into the same component. Separate classes that change at different times for different reasons into different components.
• CRP: Common Reuse Principle
  • Do not force component users to depend on things they do not need.

Component coupling principles

• ADP: Acyclic Dependencies Principle
  • There should be no cycles in the component dependency graph.
• SDP: Stable Dependencies Principle
  • Depend in the direction of stability.
• SAP: Stable Abstractions Principle
  • Components should be abstracted to the extent that they are stable.