架构从哪里开始：识别架构驱动因素

设计架构的第一步不是画框图、不是选技术栈，而是回答：什么在真正决定这个系统的架构？

为什么先学这个

多数人设计架构的起手式是"上来先画服务拆分图"或"先定技术栈"。这正是凭直觉设计的标志——结论先行，依据后补。业界所有成熟方法论（Richards & Ford 的架构特性分析、SEI 的 ATAM、arc42 的第 1/10 节）殊途同归，起点都是同一件事：先把"驱动架构的少数关键因素"找出来、写清楚，再谈方案。

这一步做好了，后面的架构风格选择、组件划分、权衡分析才有依据；做不好，整个设计过程就是在给拍脑袋的结论找补丁。

知识点一：架构决策只有三类输入

一个系统的需求可能有几百条，但真正影响架构的输入只有三类，合称架构驱动因素：

类别	说什么	例子
关键功能需求	系统"做什么"里少数会左右结构的部分	订单需要实时撮合；文件需支持断点续传
质量属性	系统"怎么样"：性能、可用性、可伸缩性、安全性、可修改性…	大促期间承受十倍流量；单点故障不影响下单
约束	不可协商的既定条件，只能服从不能权衡	必须私有化部署；团队只熟 Java；预算三人月

判断一条需求是否架构显著需求（ASR），用一个反问即可："如果这条需求变了，架构会跟着变吗？"会——它是驱动因素；不会——它只是普通需求，交给详细设计。

知识点二：驱动性质量属性，只挑 3-7 个

常见错误是列一张"我全都要"的清单：高性能、高可用、高安全、易扩展、易维护……全都要等于全都不要，因为质量属性之间天然冲突（安全的加密握手拖慢性能；强一致牺牲可用性）。

Richards & Ford 在 Fundamentals of Software Architecture 中的建议：从完整清单中挑出 3-7 个"驱动性架构特性"（driving characteristics），明确排序，其余只求"不烂"。挑选时注意两类来源：

• 显性的：需求文档里写明的（"支持 10 万并发"）。
• 隐性的：没人写但业务隐含的——支付系统没人写"要安全"，但它是排位最高的驱动因素。这类靠追问业务目标挖出来。

知识点三：把模糊诉求写成可度量的场景

"系统要高可用"这句话无法指导设计，也无法验收。SEI 的 质量属性场景方法把它改写成 6 要素句式：来源 → 刺激 → 制品 → 环境 → 响应 → 响应度量。日常使用不必六项全写，抓住核心三问即可：什么情况下（刺激+环境），系统要做到什么（响应），怎么衡量做到了（度量）。

随堂测验

实战练习：拍卖系统 Kata

经典架构 Kata 题目（来自 Architectural Katas）：

你的任务（10 分钟，写在纸上或自己的笔记里）：

1. 挑出你认为的 3 个驱动性质量属性，按重要性排序。
2. 为排第一的那个，写一条可度量的质量属性场景（刺激 → 响应 → 度量）。

写完再看：参考答案

驱动性质量属性（一种合理排序）：

1. 数据一致性/正确性——截止瞬间"谁出价最高"必须有全局唯一答案，出错直接引发资金纠纷。这是隐性属性：题目没写"要一致"，但业务性质决定它排第一。
2. 低延迟（性能）——竞价是实时对抗，出价与看到他人出价的延迟直接影响公平性和体验。
3. 可伸缩性——数千场并发、热门场次数万人，负载不均且突发。

第一名的场景示例：拍卖截止时刻（环境），多名买家在最后 1 秒内同时出价（刺激），系统裁定唯一最高有效出价并对所有参与者展示一致结果（响应），裁定结果全局一致率 100%，裁定完成 ≤ 2 秒（度量）。

你的排序和我不同不代表错——能说出"为什么这么排、牺牲了什么"就是合格的架构思考。排序不同正是团队里最值得讨论的地方。

课后延伸

主推资料源：Fundamentals of Software Architecture（Richards & Ford）第 4-5 章"架构特性"——本课知识点一、二的原始出处，中译本《软件架构：架构模式、特征及实践指南》。想看质量属性场景的完整定义，读 SEI 的 ATAM 论文第 3 节即可。

💬 本课任何地方没讲透——回到对话里直接提问，可以随时展开讲、换例子讲、或对你的 Kata 答案逐条点评。