📚 喵喵的笔记库

软件架构设计

22分钟阅读

一、全书概览

这本书是温昱写的面向程序员的架构入门书，副标题直接点明了定位——"程序员向架构师转型必备"。全书围绕"怎么从写代码的人变成做架构决策的人"这条主线展开，核心方法论是作者自创的 ADMEMS（Architecture Design Method has been Extended to Method System）。

书分三大部分：基础篇讲架构到底是什么、架构视图、设计过程；设计过程篇按六步走的需求分析→领域建模→确定关键需求→概念架构设计→细化架构设计→架构验证，用 PM Suite（项目管理套件）贯穿案例串联每一步；模块划分专题篇专门讲怎么把系统拆成模块，从粗到细、从原则到方法。

温昱的写法有个特点：他不卖弄理论，而是用大量实践案例说明"为什么这么做"。全书贯穿着一套完整的 PM Suite 案例分析，从需求分析开始一直走到细化架构设计，读者能完整看到一个架构方案是怎么一步步推导出来的。

这本书适合有 3-5 年开发经验、开始独立承担系统设计工作的程序员。如果你已经是资深架构师，可能会觉得偏基础；如果你刚入门，部分内容需要结合实际项目消化。

二、逐章要点

基础篇

第 1 章：软件架构概念

这一章解决"架构到底是什么"的问题。温昱把架构定义分为两大流派：

  • 组成派：架构 = 组件 + 交互。关注软件本身的组成结构。
  • 决策派：架构 = 重要决策集。关注人在设计过程中做的关键选择。

两个流派角度不同但互补。温昱倾向于融合两者：架构既包含系统由哪些部分组成，也包含这些决策背后的理由。

几个重要区分：

  • 框架是软件，架构不是软件。框架是半成品代码，架构是关于"怎么设计"的决策。
  • 架构比代码高一个抽象层次。代码体现架构，但任何一段具体代码都代表不了架构。
  • 架构决策是分层次的。先做技术无关的决策（系统怎么划分），再做技术相关的决策（用什么技术栈），后者在前者的指导下进行。

第 2 章：架构设计视图

一个复杂系统不可能用一个图说清楚，所以需要多个视图。Philippe Kruchten 的定义很好："一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。"

温昱强调了"分而治之"的思维：架构视图的本质就是分而治之，帮架构师从不同角度设计，尤其是面对复杂系统时这是必需的。

架构师要面对的不只是开发人员，还有用户、客户、管理者，所以架构设计要为不同角色服务。

第 3 章：架构设计过程

程序员向架构师转型的核心难点：必须能"试着做起来"，然后慢慢积累感觉和经验。

温昱提出"洞察节奏"三个原则：

  1. 看透需求（基础）
  2. 架构大方向正确（确定正确的概念架构）
  3. 设计好架构的各个方面（通过多视图方法细化架构，通过架构原型验证架构）

有经验的架构师不会一上来就定义接口，他们早期更关注识别：重大需求、特色需求、高风险需求。据此决定顶级子系统怎么划分、采用什么架构风格和开发技术、是否支持集成和二次开发——一个决定四个选型。

设计过程篇

第 4-5 章：需求分析

需求分析是架构设计的第一步，但"需求就是用户的要求"这种理解远远不够。需求分三大类：

  • 功能需求：系统要做什么
  • 质量需求：做得怎么样（性能、安全性、可扩展性等）
  • 约束需求：必须遵守什么（业务环境、技术环境、构建环境的限制）

愿景分析解决项目起源问题：业务目标 + 范围 + Feature + 上下文图。上下文图清晰描述待开发系统和周围事物的界限与联系，关注外部关系不关注内部。

用例分析是功能需求的核心工具。温昱特别强调：

  • 用例名称从参与者角度描述，以动词开头
  • 用例图 → 用例简述 → 用例规约，从泛到细
  • 需求变化的影响规律：用例图比较稳定，用例规约受变化影响最大
  • 应对策略：推后用例细化，激发需求变更

第 6-7 章：领域建模与确定关键需求

领域建模的精髓是"业务决定功能，功能决定模型"。它的作用有三：

  1. 探索复杂问题、固化领域知识
  2. 决定功能范围、影响可扩展性
  3. 提供交流基础、促进有效沟通

关键需求决定架构，其余需求验证架构——这是全书最重要的原则之一。温昱给出了确定关键需求的具体步骤，核心是从功能需求、质量属性、约束三类需求中筛选出真正影响架构的那些。

质量属性之间存在矛盾关系（比如性能和安全性经常冲突），需要通过"属性—场景—决策"表方法把模糊的质量目标细化为具体场景，再根据场景做决策。这个方法的好处：可操作性强、避免过度设计、便于后续升级参考。

第 8-9 章：概念架构设计

概念架构设计是全书的技术核心。三步走：

  1. 鲁棒性分析：基于功能需求，识别系统的保护边界
  2. 引入架构模式：选择合适的架构风格（分层、管道过滤器、MVC 等）
  3. 质量属性分析：基于质量需求，验证架构对质量的支持

概念架构是策略级别的，直指系统设计目标的设计思想和重大选择。温昱建议对比分析几种可能的概念架构，而不是拍脑袋定一个。

从概念性架构到实际架构，先构思关键问题的解决策略，再进行实际架构设计以保证为开发提供足够的指导和限制。这符合人类解决问题的规律。

第 10 章：细化架构设计

细化架构用多视图方法，5 个视图 15 个设计任务：

| 视图 | 关注点 | 设计任务 | |------|--------|----------| | 逻辑架构 | 模块划分、接口定义、领域模型 | 细化功能单元、发现通用机制、细化领域模型、确定接口和交互 | | 开发架构 | 技术选型、文件划分、编译关系 | — | | 运行架构 | 控制流划分、同步关系 | 进程和线程的规划 | | 物理架构 | 硬件分布、软件部署、方案优化 | — | | 数据架构 | 存储格式、数据分布 | — |

细化工作包括：细化功能单元、发现通用机制（机制是模式的实例）、细化领域模型、确定子系统接口和交互机制。

温昱还讨论了"架构设计到底要做到什么程度"这个问题。两句话总结：因项目和团队而异；架构应当为开发人员提供足够的指导和限制。

第 11 章：架构验证

架构验证有两种方法：原型法和框架法。

原型分四种：水平原型（模拟系统运行概貌）vs 垂直原型（深入验证具体技术问题），抛弃原型 vs 演进原型。

架构原型要验证的不是功能需求的完整性，而是架构对质量属性需求的支持程度。原型实现的功能要精心挑选：用户最关心的，或架构师最担心的。

模块划分专题篇

第 12-15 章：模块划分

模块划分是架构设计中最实际的问题之一。温昱提出了分层划分的思路：

  • 粗粒度功能模块划分：先按业务功能大块切分
  • 细粒度功能模块划分：再在模块内部进一步细化
  • 4 步骤方法：运用层、模块、功能模块、用例驱动

模块划分的核心原则：

  • 正交性：两个事物中一个变化不影响另一个，它们就是正交的
  • 高内聚低耦合：OOD 五大原则的具体体现
  • 良性依赖原则：不会在实际中造成危害的依赖都是良性依赖

温昱特别提醒要避免"高来高去"的三种症状：缺失重要架构视图、浅尝辄止不够深入、名不副实的分层架构。

第 16-20 章：深入话题

这部分涵盖了架构设计的更多实践话题：

  • 面向对象设计五大原则的详细解读（SRP、OCP、LSP、DIP、ISP）和良性依赖原则
  • 设计模式与反模式
  • 重构与架构演进
  • 软件过程与架构的关系（CMM、RUP、迭代开发）

OOD 五大原则中最值得反复体会的是依赖倒置原则（抽象不应依赖于细节，细节应该依赖于抽象），温昱称它"几乎就是软件设计的正本清源之道"。

三、关键概念速查

| 概念 | 定义 | |------|------| | 架构（组成派） | 软件 = 组件 + 交互 | | 架构（决策派） | 架构 = 重要决策集 | | ADMEMS | 作者自创的架构设计方法体系，强调需求驱动、多视图、迭代验证 | | 愿景 | 业务目标 + 范围 + Feature + 上下文图 | | 上下文图 | 描述系统与外部的界限和联系，不关注内部 | | 功能树 | 将功能大类→功能组→功能项以树形呈现的工具 | | 领域模型 | 提炼领域概念，固化领域知识的模型 | | 概念架构 | 策略级别的架构设计，关注架构风格和高层分割 | | 细化架构 | 通过多视图方法详细设计架构各个方面 | | "属性-场景-决策"表 | 把质量属性需求细化为具体场景再决策的方法 | | 架构原型 | 验证架构对质量属性支持程度的有限实现 | | 良性依赖原则 | 不会在实际中造成危害的依赖都是良性依赖 | | 正交 | 一个变化不影响另一个，多个维度独立 | | 机制 | 模式的实例，是特定上下文中重复出现问题的解决方案 | | 进程 vs 线程 | 进程是重量级控制流（分配多种资源），线程是轻量级控制流（仅分配处理机） |

四、核心框架/模型

1. 架构设计六步法（ADMEMS 核心）

需求分析 → 领域建模 → 确定关键需求 → 概念架构设计 → 细化架构设计 → 架构验证

每一步都有明确的输入输出，PM Suite 案例贯穿始终。

2. 洞察节奏三原则

  1. 看透需求（全、矛盾、追溯）
  2. 架构大方向正确（概念架构）
  3. 设计好架构的各个方面（多视图 + 原型验证）

3. 概念架构设计三步

  1. 鲁棒性分析（基于功能需求）
  2. 引入架构模式（分层、管道-过滤器等）
  3. 质量属性分析（基于质量需求）

4. 细化架构五视图

逻辑架构 / 开发架构 / 运行架构 / 物理架构 / 数据架构，共 15 个设计任务。

5. 需求三维模型

需求 = 功能需求 + 质量需求 + 约束需求

关键需求决定架构，其余需求验证架构。

6. OOD 五大原则 + 良性依赖原则

  • SRP（单一职责）：一个类只有一个引起变化的原因
  • OCP（开放封闭）：可扩展，不可修改
  • LSP（里氏替换）：子类型必须能替换基类型
  • DIP（依赖倒置）：细节依赖抽象
  • ISP（接口隔离）：多个专用接口优于一个通用接口
  • 良性依赖：务实，避免过度设计

五、金句摘录

  1. "框架是软件，架构不是软件。框架是系统或子系统的半成品。软件架构不是软件，而是关于软件如何设计的重要决策。"

  2. "关键需求决定架构，其余需求验证架构。"

  3. "架构师首要的第一步是做需求分析。"

  4. "一个决定四个选型：顶级子系统怎么划分、架构风格、开发技术、是否支持集成、是否支持二次开发。"

  5. "概念架构是策略，直指系统设计目标的设计思想和重大选择，是关乎任何复杂系统成败的最关键的指向性的设计。"

  6. "软件架构师必须牢记：关注'软件运行期质量属性'，为开发人员而设计。"

  7. "不会在实际中造成危害的依赖关系，都是良性依赖。"

  8. "依赖倒置原则几乎就是软件设计的正本清源之道。"

  9. "架构视图的本质是'分而治之'。"

  10. "从概念性架构到实际架构，先设计概念性架构，构思关键问题的解决策略；再进行实际架构的设计——这符合人类解决问题的规律。"

六、行动清单

如果你正在做系统设计

  • [ ] 画一张上下文图，明确系统边界和外部交互方
  • [ ] 列出功能需求、质量需求、约束需求三张清单
  • [ ] 从三张清单中筛选关键需求（真正影响架构的）
  • [ ] 用"属性-场景-决策"表把质量需求具体化
  • [ ] 先做概念架构（选架构风格、划子系统），再做细化设计
  • [ ] 验证架构时，挑"用户最关心"和"自己最担心"的功能做原型

如果你想提升架构能力

  • [ ] 读完整本书，跟着 PM Suite 案例走一遍六步法
  • [ ] 找一个自己参与过的项目，事后复盘用 ADMEMS 方法重新梳理一遍
  • [ ] 练习画五种架构视图，尤其是逻辑架构和物理架构
  • [ ] 学习 UML 建模（类图、包图、组件图、部署图、状态图）
  • [ ] 精读 OOD 五大原则，每个原则找一个实际项目中的正反例
  • [ ] 研究反模式（Anti-pattern），知道"不该怎么做"同样重要

团队协作建议

  • [ ] 架构文档要包含愿景、上下文图、关键需求、概念架构、细化视图
  • [ ] 用多视图方法让不同角色的人各取所需
  • [ ] 迭代开发，通过里程碑持续验证和调整架构
  • [ ] 产品线架构一定要文档化

七、一句话总结

这本书的价值不在给出某个具体的技术方案，而在建立一套"从需求出发、分步推进、多视角验证"的架构设计思维框架——对刚从写代码转向做架构设计的人来说，它补的是方法论这一课。

八、读者热议

正面评价

  • "实用性很强的架构入门书籍，内容有深有浅，涉及面广，帮我们树立一个架构设计的全局观。"（博客园读者）
  • "作为程序员向架构师转型的入门书，覆盖了架构设计的关键技能项，对架构设计过程中可能出现的各种问题给了解答。"（得到 APP 推荐）
  • PM Suite 贯穿案例的设计得到不少好评，认为比纯理论好消化。

负面评价

  • "有例子，但讲得太差劲没有讲到最要紧的地方，很难找到有内容的地方。"（豆瓣读者 shanno吳）
  • "到后面就是一堆案例，问题的关键是不告诉你为什么这么做。作者自己的架构思想是什么也没有说。这本书顶多算一个知识普及书籍。"（豆瓣读者 Squirrel）
  • "看懂的部分是在扯淡，看不懂的部分或许也在乱扯。总之两个字'空洞'。"（豆瓣读者）

争议焦点

核心争议在于深度不够。支持者认为作为入门书建立全局观就够了，反对者觉得作者没有深入讲透"为什么"，缺乏自己的架构思想。比较中肯的看法是：这本书适合 3-5 年经验的程序员建立架构方法论，但真要做大型复杂系统，还需要配合《架构整洁之道》《软件系统架构》等更深入的书一起读。另外，书中 UML 图和 ADMEMS 方法在实际工作中是否完全照搬，需要根据团队情况灵活调整。

笔记生成时间：2026-04-27

相关笔记

同作者仅有此篇 同主题：

关系图谱