罗伯特·C·马丁《架构整洁之道》深度导读

这篇文章会给大家分享一本好书，然后内容是我阅读的时候做的读书笔记：

• 在线阅读： https://geekdaxue.co/read/Clean-Architecture-zh/docs-README.md
  
• 豆瓣介绍： https://book.douban.com/subject/30333919/
  

第一部分 基础概念与核心目标

Chap 1 设计与架构到底是什么

• 本质区分：
  
  
  
  • 设计：关注模块与组件的细节组织，确保代码符合单一职责、开闭原则等微观规则。
    
  • 架构：聚焦系统高层结构，定义组件间的依赖关系、边界划分与策略层级，目标是降低长期维护成本。
    
  
  
• 终极目标：以最小人力成本实现系统全生命周期的构建与维护：
  
  
  
  • 优质架构：生命周期内修改成本稳定或下降（如通过抽象层隔离变化）。
    
  • 劣质架构：每次变更导致“熵增”，后续成本指数级上升（如模块间强耦合引发连锁反应）。
    
  
  
• 核心隐喻：“先稳后快”——架构的稳定性是效率的前提，避免为短期速度牺牲长期可维护性。
  

Ch 2 两个价值维度

• 行为价值（运行时价值）：
  
  
  
  • 直接满足用户需求的功能实现，如业务逻辑、UI交互、性能指标。
    
  • 衡量标准：用户满意度、功能完成度、响应速度等“显性价值”。
    
  
  
• 架构价值（编译时价值）：
  
  
  
  • 决定系统可维护性的底层设计，如解耦程度、依赖方向、组件独立性。
    
  • 衡量标准：修改成本、扩展难度、团队协作效率等“隐性价值”。
    
  
  
• 艾森豪威尔矩阵应用：
  
  
  
  • 紧急且重要：短期功能交付（行为价值）与关键架构决策（如核心业务抽象）需平衡。
    
  • 重要不紧急：持续优化架构（如依赖倒置、接口隔离），避免陷入“技术债务”陷阱。
    
  
  

第二部分 编程范式与设计原则

Ch 4 结构化编程（补充缺失内容）

• 核心思想：通过顺序、分支、循环三种基本结构控制程序流程，避免GOTO语句导致的逻辑混乱。
  
• 架构影响：
  
  
  
  • 清晰的控制流是组件交互的基础，确保代码可预测性与可测试性。
    
  • 函数设计应遵循“单一出口”原则，降低调试复杂度。
    
  
  
• 与架构结合：结构化编程是“过程式设计”的基石，为后续面向对象、函数式编程提供底层逻辑框架。
  

Ch 5 面向对象编程

• 三大特性对架构的支撑：
  
  
  
  • 封装：隐藏实现细节，暴露稳定接口，降低模块间认知成本（如将数据库操作封装为Repository接口）。
    
  • 继承：通过抽象类定义高层策略（如业务规则），子类实现具体细节（如不同数据库方言），符合DIP原则。
    
  • 多态：核心价值在于控制依赖方向——高层模块依赖抽象接口，底层模块实现接口，实现“插件式架构”（如更换UI框架不影响业务逻辑）。
    
  
  
• 独立开发/部署能力：
  
  
  
  • 组件通过接口交互，允许不同团队并行开发（如前端团队与后端团队约定API契约），编译时依赖仅指向抽象层，支持独立构建与部署。
    
  
  

Ch 7 SRP：单一职责原则

• “职责”的精准定义：
  
  
  
  • 职责是“变化的原因”，而非功能模块或代码行数。
    
  • 例：用户管理模块中，“用户验证”（响应产品需求）与“日志记录”（响应运维需求）属于不同职责，需拆分独立类。
    
  
  
• 实践价值：
  
  
  
  • 减少代码变更的“涟漪效应”，确保修改某类用户需求（如产品经理要求的业务规则）时，仅涉及单一模块。
    
  
  

Ch 11 DIP：依赖倒置原则

• 三层依赖规则：
  
  
  • 高层模块（如业务逻辑）不依赖底层模块（如数据库驱动），两者共同依赖抽象接口。
    
  • 抽象接口不应依赖具体实现，具体实现必须依赖抽象接口（如定义UserRepository接口，由MysqlUserRepository和MongoUserRepository实现）。
    
  • 避免在抽象层引入具体实现的细节（如接口中不出现ResultSet等数据库特定类型）。
    
  
  
• 反模式警示：
  
  
  
  • 高层模块直接调用底层类（如业务逻辑中写入new MysqlConnection()），会导致底层变动污染整个系统。
    
  
  

第三部分 组件设计与耦合控制

Ch 13 组件聚合三原则

• 复用/发布等同原则（REP）：
  
  
  
  • 组件（包）是复用与发布的最小单元，若多个类需共同发布，则应归入同一包（如Spring框架的core包与web包独立发布）。
    
  • 违反后果：用户被迫依赖冗余代码（如为使用一个工具类引入整个库）。
    
  
  
• 共同闭包原则（CCP）：
  
  
  
  • 同包类应因相同原因修改（如用户认证相关的UserService与AuthInterceptor），避免将“用户管理”与“日志监控”混放。
    
  • 实践：按“变更轴心”分组，如将所有与“支付策略”相关的类放入payment-strategy包。
    
  
  
• 共同复用原则（CRP）：
  
  
  
  • 同包类应被共同复用，若用户仅需其中一个类，则说明包内存在低内聚（如将StringUtils与DateUtils拆分独立工具包）。
    
  
  

Ch 14 组件耦合：稳定性与抽象度

• 稳定依赖原则（SDP）：
  
  
  
  • 不稳定性度量公式：I = 依赖数 / (依赖数 + 被依赖数)（范围0-1，I=0表示完全稳定，I=1表示完全不稳定）。
    
  • 例：组件A被2个组件依赖，自身依赖1个组件，则稳定性S = 1 - I = 2/3，应确保依赖方向为低稳定性→高稳定性（A→B要求S(B)≥S(A)）。
    
  
  
• 稳定抽象原则（SAP）：
  
  
  
  • 稳定的组件（如核心业务规则）应包含抽象接口（如领域模型中的OrderService接口），而非具体实现。
    
  • 不稳定的组件（如UI框架适配层）可包含具体实现，便于快速迭代。
    
  
  
• 环形依赖解决方案：
  
  
  
  • 接口提取法：在两个组件间定义中立接口，由双方共同依赖（如PaymentService接口位于独立包，支付实现与订单模块均依赖该接口）。
    
  • 防腐层（ACL）：在依赖方向上添加中间层，隔离直接依赖（如旧系统与新系统通过ACL交互，避免双向耦合）。
    
  
  

第四部分 架构设计核心思想

Ch 15 什么是软件架构

• 架构师的核心任务：
  
  
  • 定义系统边界与组件依赖方向（如业务逻辑层不依赖UI层）。
    
  • 分离“策略”与“细节”：高层策略（如订单计算规则）不依赖底层细节（如Redis缓存实现）。
    
  • 最大化“可选项”：通过抽象层允许未来替换实现（如从单体架构平滑迁移至微服务）。
    
  
  
• 初期设计禁忌：
  
  
  
  • 过早陷入技术选型（如争论使用MySQL还是PostgreSQL），应优先确定业务策略的层次结构。
    
  
  

Ch 16 独立性：康威定律与分层架构

• 康威定律实践：
  
  
  
  • 组织架构决定系统架构，应按业务领域划分团队（如电商分为“订单团队”“支付团队”），对应系统模块边界。
    
  • 反例：技术团队按“前端/后端”划分，可能导致跨团队协作时的接口频繁变更。
    
  
  
• 经典分层架构：
  1. （外层，易变）UI → 应用服务 → 领域模型（核心，稳定） ← 基础设施（数据库、工具）  

  复制代码
  
  
  • 依赖方向：外层依赖内层抽象，内层不依赖外层具体实现（如领域模型不包含HTTP或SQL代码）。
    
  
  

Ch 19 策略与层次：构建有向无环图（DAG）

• 策略分类标准：
  
  
  
  • 变更原因：同类需求（如“促销策略”相关逻辑）应集中在同一组件。
    
  • 变更时间：需同时修改的策略（如订单超时与库存回滚规则）应耦合在同一层次。
    
  • 层次位置：离输入/输出（如API接口、数据库驱动）越远，层次越高（领域模型层＞应用服务层＞基础设施层）。
    
  
  
• 典型依赖链：
  1. 外部输入（HTTP请求）→ 控制器（解析参数）→ 应用服务（调用领域逻辑）→ 领域实体（核心计算）→ 仓储接口（抽象数据操作）→ 具体仓储实现（数据库交互）  

  复制代码
  
  
  • 底层（仓储实现）依赖高层（仓储接口），符合DIP原则。
    
  
  

Ch 20 业务实体：架构的皇冠明珠

• 实体的核心特征：
  
  
  
  • 包含关键业务数据（如订单中的“总价”“折扣规则”）与不可变业务逻辑（如计算税费、校验库存）。
    
  • 与技术细节解耦：不依赖框架（如Hibernate注解）或基础设施（如HTTP客户端），确保跨平台复用。
    
  
  
• 与数据模型的区别：
  
  
  
  • 数据模型（如数据库表结构）关注存储格式，业务实体关注领域规则，两者通过仓储层转换（如OrderEntity与OrderDAO的映射）。
    
  
  

CH 27 服务：架构边界的本质

• 服务拆分的误区：
  
  
  
  • 按“技术栈”（如用户服务、商品服务）拆分可能导致跨服务策略耦合（如修改订单策略需同步更新库存服务）。
    
  • 正确方式：按“策略层次”拆分，确保每个服务内部组件依赖方向一致（如核心策略服务→通用工具服务）。
    
  
  
• 架构边界 vs 服务边界：
  
  
  
  • 架构边界存在于服务内部（如服务内的领域层与基础设施层边界），比服务间边界更重要。
    
  • 微服务解决的是运维问题（如独立扩容、技术栈异构），但无法自动解决架构问题（如依赖混乱需通过DIP在服务内控制）。
    
  
  
• 关键结论：
  
  
  
  • 系统架构由组件间的策略依赖关系定义，而非服务间的通信协议（HTTP/gRPC）或部署形态（单体/分布式）。
    
  
  

第五部分 补充与强化

Ch 28 测试：依赖稳定的抽象

• 测试原则：
  
  
  
  • 单元测试依赖抽象接口（如通过Mock仓储接口测试领域逻辑），而非具体实现（如真实数据库）。
    
  • 避免测试依赖易变组件（如第三方API客户端），通过适配器模式隔离外部变化。
    
  
  

依赖关系守则强化

• 四大原则协同：
  
  
  • DIP确保依赖指向抽象，打破高层与底层的直接耦合。
    
  • ISP避免依赖冗余接口，缩小组件间的契约范围。
    
  • 迪米特法则限制组件间的交互深度，降低认知复杂度（如方法参数避免传递无关对象）。
    
  • 单向依赖构建DAG依赖图，杜绝环形依赖导致的编译/部署阻塞。
    
  
  

总结：架构设计的本质

• 核心矛盾：平衡“当前交付效率”与“未来维护成本”，通过抽象、解耦、分层将易变部分隔离在系统边缘，稳定核心业务逻辑。
  
• 终极目标：构建“反脆弱”架构——外部变化（如技术选型、团队调整）仅影响边缘组件，核心策略保持稳定，实现“以不变应万变”。
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！