Source
Review on tellmeabout.tech
Article from the Code of Architecture club - part 1
Clean Architecture: A Craftsman's Guide to Software Structure and Design
Authors: Robert C. Martin
Publisher: Pearson, 2017
Length: 432 pages
Classics from Uncle Bob: SOLID principles, component cohesion and coupling, Main Sequence and plugin architecture.
Original
TranslatedIntroduction: Design and Architecture
The main thesis of the book's introduction is simple and ambitious:
"When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between."
Architecture = Design?
According to the author, there is no difference between architecture and design - it is a single continuum from high-level structures to low-level details.
Main conclusion
“The only way to go fast, is to go well” - the right architecture pays off in the long run.
Related book
A Philosophy of Software Design
Ousterhout also talks about dealing with complexity and strategic programming
Two aspects of software value
Every software system has two aspects of value for stakeholders:
Behavior
Functional requirements - how the system works. Important for business. Usually perceived as "urgent".
Structure
Architectural aspects - difficulty of making changes. Important for the team. Usually perceived as "important".
The author suggests using the Eisenhower matrix for decision making. The problem is that business managers often elevate urgent but unimportant tasks, putting off important architectural decisions.
"It is the responsibility of the software development team to assert the importance of architecture over the urgency of features."
Programming Paradigms
There are three main programming paradigms, each of which imposes limitations and has architectural implications:
| Paradigm | Limitation | Advantage | For architecture |
|---|---|---|---|
Structured Programming | Ban goto | Decomposition into testable functions | Functional decomposition |
Object-Oriented Programming | Safe polymorphism | Plugin architecture, DIP | Component Separation |
Functional Programming | Immutability | No race conditions | Segregation of Mutability |
Structured Programming
Dijkstra proved that any program can be constructed from three structures:sequence,selection,iteration.
"Testing shows the presence, not the absence, of bugs" — Dijkstra
Object-Oriented Programming
OOP is a combination of encapsulation, inheritance and polymorphism. From an architect's point of view, the most important thing is polymorphism, which provides dependency inversion and independent development/deployment.
"OO is the ability to gain absolute control over every source code dependency in the system."
Functional Programming
The main feature is the immutability of variables. For architecture, this means the absence of race conditions and deadlocks. This is where the Event Sourcing pattern comes from.
"Event sourcing is a strategy wherein we store the transactions, but not the state."
Part 2
Review on tellmeabout.tech
SOLID and Component Principles
Design Principles (SOLID)
The SOLID principles are aimed at creating mid-level software structures that:
- Tolerant of change
- Easy to understand
- They are the basis for reusable components
SOLID principles
Click on the letter for details
SSingle Responsibility Principle
Not "a function should do one thing", but a module must be responsible to one actor. Symptoms of the violation: accidental duplication and merge conflicts.
OOpen-Closed Principle
The artifact must be open for expansion, but closed for modification. This is one of the driving factors in system architecture.
LLiskov Substitution Principle
Subtypes must be interchangeable with base types. Violation of this principle leads to “sprawling” logic with alternative branches.
IInterface Segregation Principle
The client should not depend on methods it does not use. At the architectural level: do not depend on components with redundant functionality.
DDependency Inversion Principle
The most flexible systems are those in which dependencies in the source code refer only to abstractions. Use the Factory pattern for dependency inversion.
Dependency Inversion with Factory pattern
How to invert dependencies using abstractions
Problem: direct dependence
Application directly depends on ConcreteImpl - DIP violation
Related book
Fundamentals of Software Architecture
Richards and Ford develop component coupling theme through Connascence
Component Principles
Components are units of deployment. After 50 years of development, we have come to plugin architecture as a standard.
Component Cohesion
Three principles govern how to break down classes into components:
REP
Reuse/Release Equivalence
Classes that are released together should have a common theme or purpose.
CCP
Common Closure
Collect classes into components that change for the same reasons and at the same time.
CRP
Common Reuse
Don't make component users depend on things they don't need.
Tension Diagram: Component Cohesion
The architect balances these principles depending on the needs of the project
Component Coupling
Three principles govern the relationships between components:
ADP: Acyclic Dependencies Principle
Avoid loops in your component dependency graph.
The dependency graph must be a directed acyclic graph (DAG). To eliminate loops, use DIP.
SDP: Stable Dependencies Principle
Depend in the direction of stability.
Metrics: FanIn (incoming), FanOut (outgoing), I = FanOut / (FanIn + FanOut). I=0 - completely stable, I=1 - completely unstable.
SAP: Stable Abstractions Principle
A component should be as abstract as it is stable.
Metric: A = Na / Nc (number of abstract classes to total number). Mix SAP + SDP = DIP for components.
Main Sequence и зоны риска
Идеальная диагональ: баланс между абстрактностью и стабильностью. Формула: D = |A + I - 1|
Конкретные и стабильные компоненты (A≈0, I≈0). Сложно менять, так как много зависимостей.
Абстрактные и нестабильные компоненты (A≈1, I≈1). Абстракции без реализаций.
Key Findings
Architecture is important
"If architecture comes last, then the system will become ever more costly to develop."
Plugin Architecture
OOP makes it possible to create plugin architectures with independent development and deployment.
Evolution of structure
The structure of components must evolve over time - it cannot be designed once and for all.
Main Sequence
Components should be placed along the main sequence, avoiding areas of "pain" and "uselessness".