本篇要回答的问题：既然有那么多耳熟能详的架构原则，为什么熟读它们仍不足以成为优秀架构师？架构师真正的武器库到底是什么？
上一讲讲完接口设计，架构思维篇已近尾声。许式伟一直没从那些大名鼎鼎的原则讲起，本讲正面解释为什么——原则很好，但它们只是"思维"，而软件工程的复杂性不会因好思维而消除。本讲点明：架构师真正的武器库是消化了的基础架构 + 不断沉淀的架构范式。
那些耳熟能详的架构原则（很好，但不是武器库）
| 原则 | 缩写 | 核心 |
|---|---|---|
| 接口隔离原则 | ISP | 模块间依赖应依赖于尽可能小的接口 |
| 依赖倒置原则 | DIP | 高层不依赖低层，二者都依赖抽象接口 |
| 无环依赖原则 | ADP | 不要出现循环依赖（解法见 DIP） |
| 组合/聚合复用原则 | CARP | 扩展功能优先用组合而非继承 |
| 高内聚低耦合 | HCLC | 模块内聚、模块间松耦合 |
| 惯例优于配置 | COC | 非必须的灵活性就别要，尽量零配置 |
| 命令查询分离 | CQS | 读写操作分离，命令与查询不揉一起 |
| 关注点分离 | SOC | 把复杂问题拆成多个简单问题——但难在如何分 |
关键判断：熟读架构思维并不足以让人成为优秀架构师。我们做的是软件工程，其复杂性自然存在，不因好思维而消除。 架构师真正的武器库不是这些原则。
架构师真正的武器库：基础架构 + 架构范式
OCP 告诉我们软件可"搭积木"搭出来，关键是如何形成更多业务只读、接口稳定、易于组合的"积木"。真正提高工程效率的是业务分解能力 + 历史积累的成果。武器库由两块构成：
其一：信息科技形成的基础架构（要消化到"同频共振"）
| 层级 | 包含内容 |
|---|---|
| 基础平台 | 冯·诺依曼体系、编程语言、操作系统 |
| 桌面开发平台 | 窗口系统、GDI 系统、浏览器与小程序（背后是 MVC 架构） |
| 服务端开发平台 | 负载均衡、各类存储中间件（服务端难在形成有效基础架构，大部分是存储中间件） |
| 服务治理平台 | 以容器为核心的 DCOS（数据中心操作系统）及服务治理生态，仍高速发展中 |
洞见：有些人看起来博学多才、头头是道，但真做架构时完全想不到他的"博学"。只有让基础架构完全融入思维体系、同频共振，才可能在需要时"想到它们"。消化基础架构远比消化原则难，而消化它的过程同时也是消化架构思维的过程——把虚的事情往实里做。
其二：自己沉淀的业务架构武器库
业务一般没有统一体系可参考（有的话早被基础设施化了），只能靠自己的架构设计能力构建——这也是架构师的乐趣。其中尚未被基础设施化但通用的，是数据相关体系（数据是软件的灵魂）：
| 通用数据子课题 | 说明 |
|---|---|
| 存盘与读盘（IO） | —— |
| 文本处理 | 下一讲专门展开 |
| 存储与数据结构 | —— |
| Undo/Redo | —— |
设计场景 > 设计模式
关键判断：与其谈常规"设计模式"，不如谈"设计场景"。区别在于：设计场景有清晰的问题域定义，是一个实实在在的通用子系统。架构师若总能把业务场景分解为多个"通用设计场景"的组合，就代表他有了极强的架构范式抽象能力——这正是架构师成熟度的核心标志。
总结
架构原则虽好，但只是思维，消除不了软件工程的固有复杂性。架构师真正的武器库 = 消化到同频共振的基础架构 + 自己不断沉淀的、有清晰问题域的通用设计场景。这也解释了整门架构课为何先用四章讲信息科技演进史——因为消化基础架构最难。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 架构范式 | 业务只读/接口稳定/易组合的模块 + 组合的方法论 |
| 武器库 | 基础架构 + 自沉淀的业务架构范式，而非架构原则 |
| 同频共振 | 把基础架构消化进思维，需要时自然"想到它们" |
| 设计场景 | 有清晰问题域定义的通用子系统，优于"设计模式" |
一句话速记
架构原则只是"思维"，真正的武器库是消化到同频共振的基础架构加上有清晰问题域的通用设计场景——把虚的往实里做，才成得了优秀架构师。
几条值得记住的判断
- 熟读原则≠会做架构，软件工程的复杂性不会因好思维而消除。
- 博学若不能同频共振，做架构时根本想不起来。
- 设计场景优于设计模式，因为它有清晰问题域、是真实子系统。
思考题
回顾你过去解决过的若干业务，能不能从中提炼出至少一个"有清晰问题域定义的通用设计场景"，让它沉淀为你个人的可复用积木？如果提炼不出来，是问题域没想清楚，还是分解还不够正交？
