Why Mastering Architecture Principles Keeps Your Code Future‑Proof

This article is a reading note of the book "Clean Architecture". The author reorganizes the book’s content, adds personal insights, and provides a detailed knowledge map to help readers grasp the essence of the book.

1. Value of Software Systems

Software architecture is part of a software system, so understanding architecture value starts with understanding software system value, which includes behavior value and architecture value.

Behavior value covers core functionality, usability, performance, and stability—about 90% of engineers' work. When business requirements are clear and stable, architecture value can be ignored; otherwise, architecture becomes crucial to keep the software "soft".

When requirements change, software changes should be simple and convenient.

The difficulty of implementing a change should be proportional to the scope, not the shape of the change.

If only behavior value is considered, code growth stabilizes while change cost per line rises, leading to reduced productivity and higher company costs.

From the urgent‑important matrix, behavior‑value tasks are usually urgent but not always important, while architecture‑value tasks are important but not urgent. Engineers should separate the two before writing code.

2. Goals of Architecture Work

The goal is to achieve architecture value with minimal human cost, supporting the full lifecycle of the system: understandable, modifiable, maintainable, and easily deployable.

Development: avoid heavy scaffolding; separate teams for different components.

Deployment: minimize scripts and configuration files; reduce component count.

Runtime: consider throughput and latency; expose use‑cases, functions, and classes clearly.

Maintenance: reduce exploration cost and risk when locating or fixing issues.

3. Programming Paradigms

Architecture imposes limits on where source code lives, dependencies, and communication methods. Programming paradigms are the fundamental limits on control flow and data flow.

3.1 Structured Programming limits direct control transfer (e.g., goto) and enables reasoning about program correctness.

3.2 Object‑Oriented Programming introduces encapsulation, inheritance, and polymorphism; polymorphism enables safe component communication and underpins Dependency Inversion.

In non‑OO languages, function pointers are used for decoupled communication, but they are fragile. Example:

struct FILE {
    void (*open)(char* name, int mode);
    void (*close)();
    int (*read)();
    void (*write)(char);
    void (*seek)(long index, int mode);
}

3.3 Functional Programming emphasizes pure functions without side effects, helping avoid mutable‑state problems such as concurrency bugs.

4. Design Principles

Design principles guide how to organize data and functions into classes, link classes into components, and ultimately shape the architecture.

OCP (Open‑Closed Principle): software should be extensible without modification.

SRP (Single Responsibility Principle): each module has one reason to change.

LSP (Liskov Substitution Principle): interchangeable implementations must not alter system behavior.

ISP (Interface Segregation Principle): depend only on methods you actually use.

DIP (Dependency Inversion Principle): dependencies should point opposite to control flow.

REP (Reuse‑Publish Equivalence): reuse granularity equals publish granularity.

CCP (Common Closure Principle): classes that change together belong in the same component.

CRP (Common Reuse Principle): a component should not force others to depend on unnecessary functionality.

No Dependency Cycle: dependencies form a directed acyclic graph.

Stable Dependency Principle: depend on more stable components.

Stable Abstraction Principle: abstraction level should match stability.

5. Basic Guidelines for Architecture Work

Preserve as many optional design choices as possible (e.g., storage, database, framework) and decouple business code from these choices. Use the lowest‑level decoupling that satisfies the need; avoid higher‑level decoupling when unnecessary.

6. Component Splitting

A component is a set of strategies that transform inputs to outputs, sharing the same change reason, time, and level.

Components should be split by:

Change reason (business use‑cases): e.g., order component, chat component.

Level: business entities, use‑cases, interface adapters, framework & drivers.

Higher‑level strategies are farther from system I/O; business entities are highest, framework/driver is lowest.

7. Component Dependency Handling

Dependencies should flow from lower‑level components to higher‑level ones, keeping data flow and control flow separate.

8. Component Boundary Handling

A complete boundary includes abstract interfaces for both sides, dedicated input and output data models. When possible, use incomplete boundaries to reduce maintenance cost, such as omitting the final split step, single‑direction boundaries, or portal patterns.

Boundary decoupling can be at three levels:

Source‑code level: interfaces and class dependencies within the same component.

Deployment level: independently deployable components (e.g., static/dynamic libraries).

Service level: components run on different machines communicating via URLs or network packets.

Cost rises from development to deployment; choose the lowest level that satisfies the requirement.