软件架构认知：从“少林 vs 武当”到你自己的定义软件架构认知：从“少林 vs 武当”到你自己的定义目标读者：一线开发

目标读者：一线开发工程师 & 准架构师。

这一章想解决的问题只有一个：到底什么是软件架构？
你会发现，不同大师给的定义都不一样，但最后会收敛到两个关键词：组成和决策。

一、两派之争：少林的“组成派”，武当的“决策派”

一个很有画面感的比喻：

少林派 = 组成派：
- 天下武功出少林：一招一式、一层一层堆出来；
- 对应到架构：模块、组件、服务、系统，一层一层拆分和组合。
武当派 = 决策派：
- 卜算天机、定人生走向：重在“怎么选”；
- 对应到架构：选云还是机房、选开源还是自研、选单体还是微服务、选 K8s 还是 Mesos……

现实中的你，大概率也会偏某一派：

几大致可以看成两类：

甚至 IEEE 那样的“官方定义”，一开始也在说“结构和组件”，最后还是会补一句：
架构要持续演化来响应新需求 —— 而演化背后，必然是连续的决策。

可以把各种定义粗暴归纳成一句话：

软件架构 = 重要的结构 + 背后的重要决策及其理由。

如果把你日常做的事拆开看，大致有两条主线：

组成线（少林线）：
- 画用例图、类图、组件图、部署图；
- 做“高内聚、低耦合”的模块划分；
- 按领域划分子域、聚合、实体、值对象；
- 按层次拆服务：接口层、应用层、领域层、基础设施层……
决策线（武当线）：
- 选技术栈、选中间件、选云厂商；
- 评估不同方案的成本、风险、可扩展性、维护成本；
- 写下“选 A 不选 B 的原因”和“接受了哪些 trade-off”；
- 在评审会上说服产品 / 研发 / 运维，让大家对同一方案点头。

如果你只做组成，不做决策，你容易变成“高级画图工程师”；
如果你只做决策，不懂组成细节，你容易变成“嘴上架构师”。

真正靠谱的架构师，往往是“中间派”：一手能落图，一手能拍板。

书里用“莫扎特作曲”来类比“架构设计”，提出了架构的六个目标（这里只保留易落地的版本）：

桥梁：
- 莫扎特的音乐是自己和听众之间的桥梁；
- 架构是业务诉求和技术落地之间的桥梁。
指引 / 蓝图：
- 乐谱指导乐队演奏；
- 架构蓝图指导开发和运维协作，实现“按图施工”。
合理地“分乐章”：
- 大乐章拆成可记忆的小乐章，每段都有主题和高潮；
- 架构要把系统拆成“既不太碎也不太大”的模块 / 子域，每块都有明确职责。
多声部交互：
- 钢琴、弦乐、管乐互相配合、呼应；
- 系统中的模块 / 服务要通过合适的交互方式（同步调用、异步消息、事件驱动等）协作。
持续打磨细节：
- 莫扎特会在已足够优秀的乐谱上反复改动；
- 架构师要在大方向定好后，不断优化小的设计细节（接口、表结构、缓存逻辑等）。
演进而不是重来：
- 莫扎特早期到晚期风格在变，但主基调还在；
- 架构要在满足新业务、新技术的前提下，保留系统的稳定“基调”，通过演进而不是每次推倒重做。

如果你面试被问“架构的作用是什么”，直接从这六个目标里挑三四个结合项目来讲，非常有说服力。

作者把软件架构的发展粗分成三代，你可以用来“定位”自己目前的思维在哪一代。

这阶段“架构感”还很弱，更多是“程序设计”的层面。

这时“架构”开始有点轮廓，但常常还停留在“代码级设计”。

UML、组件模型（CBM）、SOA 等出现后，开始强调：
- 如何拆系统（组件 / 服务 / 子域）；
- 如何画多种架构视图（逻辑、部署、运行时）；
- 如何用方法论组织整个设计过程。

再往后，作者提到几种典型方法：

你可以粗略对照一下自己：

这一章的知识，最直接的用法有两个：

面试 / 晋升答题素材：
- “你怎么理解软件架构？”
- “架构的职责 / 价值是什么？”
- “你更偏哪种风格的架构师？”
  你都可以用「组成派 vs 决策派 + 莫扎特六目的 + 三代发展」来组织答案。
日常实践的自查表：
- 最近这个系统的设计里，我只是在“拆模块”，还是也有在“记录关键决策”？
- 我是不是能说清楚：这个系统的“桥梁作用”、“指引作用”、“分割与交互设计”、“演进路线”？
- 我现在做的，是“第二代的模式级设计”，还是已经在用“第三代的方法论和多视角”？

当你能用这一套语言稳定地描述自己做的系统设计时，你对“软件架构”的认知，基本就从“模糊感觉”进化到了“可解释、可传递”的层级。