Books Notes Graph Series Tags

架构之道

📅 2026-04-01 ✏️ 2026-04-01 BN
No related notes

1 · 读书笔记：架构之道

Righting Software: A Method for System and Project Design https://book.douban.com/subject/35563799/

S 软件项目经常失败，不只是因为代码写得差，更因为系统设计和项目设计长期被割裂。 C 业界习惯按需求、功能或领域直接拆系统，但需求天然会变，架构也就跟着反复返工。 Q 那应该如何设计软件系统，才能同时更抗变化，也更容易估算工期、成本与风险？ A 作者给出的答案是 The Method = System Design + Project Design：先基于易变性做系统设计，再从系统设计推导项目设计。

一句话补充如下点：

  • 是什么（What）：这本书提出一个“系统设计 + 项目设计”的完整方法，而不是只谈架构图怎么画。
  • 为什么（Why）：如果架构只对齐当前需求，不对齐变化来源，系统很快会被变化拖垮，项目也无法稳定交付。
  • 怎么做（How）：先识别变化，把变化封装进合适的服务与层次；再基于架构做活动拆分、关键路径分析和资源配置。

1.1 · 核心观点

1.1.1 · 1. 架构不只是系统设计，还包括项目设计#

这本书最重要的切入点，是把软件设计重新定义为两部分：

  • System Design：系统如何拆分、如何协作、如何承载变化
  • Project Design：项目如何排期、估算、分配资源、管理风险

作者认为，很多团队把“架构”理解成技术选型、模块划分、接口设计，但这只完成了一半。真正成熟的架构师，不只是设计系统本身，也要给出可执行的交付方案，让管理层能在时间、成本、风险之间做选择。

1.1.2 · 2. 不要围绕需求做设计，而要围绕变化做设计#

这是全书最强的一条原则。

  • 错误方式：根据当前需求、当前功能、当前用例直接拆模块
  • 正确方式：识别系统未来最可能变化的地方，并把这些变化封装起来

作者反对“按需求设计”的原因很直接：需求必然变化，而如果架构结构直接映射需求结构，那么每次需求变化都会推动架构变化，代价极高。

1.1.3 · 3. 避免功能式拆分，也不要机械地按领域拆分#

书中重点批评的是 functional decomposition。

问题通常包括：

  • 服务难复用
  • 客户端集成复杂度上升
  • 依赖关系蔓延
  • 服务数量爆炸或边界失真
  • 一旦需求变化，多个模块要一起改

作者给出的替代方案是 volatility-based decomposition，也就是基于易变性拆分。

1.1.4 · 4. 架构设计的目标不是“覆盖当前需求”，而是“可组合地应对未来变化”#

作者强调 composable design：

  • 先找到最小的一组核心构件
  • 再通过不同组合满足不同需求
  • 这样变化更多发生在组合关系，而不是底层结构本身

这比“每来一个需求，就多一个模块或分支逻辑”更稳定。

1.1.5 · 5. 项目设计要从系统设计推导出来#

系统设计确定之后，项目设计才有基础。

项目设计关心的是：

  • 活动拆分
  • 依赖关系
  • 工作量估算
  • 关键路径
  • 人员配置
  • 成本与风险

这意味着，架构师不能只画结构图，还要回答“这个设计要多久做完、哪里是高风险、有哪些交付选项”。

1.2 · 分章节理解

1.2.1 · 方法总览

全书的方法可以压缩成一句话：

先做正确的系统分解，再做可执行的项目设计。

它不是单纯的架构风格建议，而是一个从架构到交付的一体化方法。

1.2.2 · 系统设计部分

系统设计是全书前半部分，也是最值得反复读的部分。

我理解它主要回答三个问题：

  1. 系统应该按什么原则拆？
  2. 拆完以后，各层、各服务如何组织？
  3. 怎样保证需求变化时，结构尽量不跟着变？

作者的答案是：

  • 不按功能拆
  • 不直接按需求拆
  • 基于变化来源拆
  • 用分层、服务边界和组合关系来控制耦合

这里最有价值的，不是“又一种微服务拆分建议”，而是它明确把“变化”当成设计对象。

1.2.3 · 项目设计部分

项目设计部分是很多技术书不会认真展开的内容，但这本书把它纳入架构师职责。

作者强调：

  • 项目不是线性执行，而是依赖网络
  • 关键路径分析是项目设计中最重要的技术之一
  • 资源分配不能只看谁有空，而要看 float、依赖和风险
  • 管理层需要的不是一个唯一计划，而是多个可权衡的执行选项

这部分让我重新理解了“架构师影响交付”的真正含义。

1.3 · 启发点（关键洞察）

  1. 真正稳定的架构，不是最贴合当前需求的架构，而是最能吸收变化的架构。
  2. “需求驱动设计”听起来合理，但如果设计结构直接映射需求结构，需求一变，系统就会跟着变。
  3. 服务拆分的核心不是名词是否好听，而是边界是否真的封装了变化。
  4. 架构质量不仅体现在运行时质量，也体现在是否能导出可执行、可估算、可管理的项目计划。
  5. 架构师如果不给出多个交付选项，本质上是在把管理决策外包给运气。

1.4 · 我自己的理解

这本书最有冲击力的地方，不是它反复讲“微服务怎么拆”，而是它把“架构”从静态结构图，重新拉回到一个更完整的工程问题：

  • 系统为什么这样拆
  • 这种拆法能承受哪些变化
  • 它会如何影响团队协作和交付节奏

也就是说，架构的好坏不能只看“优不优雅”，而要看：

  • 变化来了是不是能局部吸收
  • 团队是不是能并行工作
  • 项目是不是能估算和控制风险

这比很多只谈模式、不谈交付的架构书更落地。

1.5 · 行动：

  1. 做系统设计时，先问“哪里会变”，再问“现在要做什么功能”。
  2. 评审服务边界时，不再只看领域名词是否漂亮，而是看变化是否被真正封装。
  3. 在方案设计阶段补上项目设计视角，至少给出关键路径、依赖和资源配置的初稿。
  4. 输出方案时，尽量提供两到三个交付选项，而不是只给一个“标准答案”。
  5. 复盘历史项目时，重点检查是否犯了“按当前需求直接长出结构”的错误。

1.6 · 金句：

  1. The Method = System Design + Project Design
  2. 不要围绕需求设计系统，而要围绕变化设计系统。
  3. 架构的价值不只是满足当前需求，而是让未来变化的代价可控。
  4. 关键路径分析不是项目管理细节，而是架构影响交付的核心抓手。

1.7 · 适合怎么读

这本书更适合带着问题读，而不是顺着翻。

建议带着下面几个问题复读：

  1. 我现在的系统边界，是按功能拆的，还是按变化拆的？
  2. 哪些模块看似独立，实际上必须一起变更？
  3. 如果需求新增一类场景，变化会扩散到几个服务？
  4. 我的架构方案，能不能自然推导出排期、成本和风险？
  5. 管理层拿到我的方案后，是否真的拥有可比较的选项？

1.8 · 参考