架构不是一次定终身的图
很多团队把架构画成一张漂亮的图，贴在墙上就以为完事了。但架构真正的价值不在那张图，而在于一系列被做出的取舍：为什么拆成这几个模块、为什么用这个中间件、为什么这里要做高可用。这些取舍如果不留下来，几个月后就没人说得清当初为什么这么选。
架构评估与演进要做的，就是把这些看不见的权衡变成看得见、可讨论、可追溯的东西。
架构文档最大的风险，不是画得不好，而是没人记得当初为什么这么决定。
- 质量属性先明确架构要为哪些目标负责。
- ATAM结构化地找出风险点与权衡点。
- ADR用一页纸把重要决策记录下来。
- 可追溯每一次架构变化都有记录可查。
- 共同语言让团队对架构有一致的理解。
架构评估：先找出有哪些风险点
架构评估不是打分比高低，而是在代价还没付出之前，把可能出问题的地方提前暴露出来。它通常围绕几个关键问题展开：这个架构撑得住预期的增长吗？某个核心模块挂了会怎样？团队真的能改得动它吗？
| 要问的风险 | 具体担心 |
|---|---|
| 性能与容量 | 流量涨十倍还撑得住吗 |
| 可用性 | 单点故障会不会拖垮全站 |
| 可修改性 | 改一个需求要动几个模块 |
| 团队协作 | 边界是否清晰、职责是否重叠 |
把这些担心一条条摆到桌面上，比等到线上出问题再回头补课划算得多。
质量属性：架构为哪些目标负责
一个架构好不好，不能空泛地说「先进」。它必须对应到具体的质量属性——也就是这个系统要在哪些方面表现出色。不同的属性之间常常互相拉扯，这正是权衡的来源。
- 性能：响应要快、吞吐要高。
- 可用性：尽量少出故障、出了能快速恢复。
- 可维护性：改动容易、不容易牵一发动全身。
- 可扩展性：业务涨上来时能从容扩展。
# 质量属性不是越多越好
- 全都要极致，等于架构谁也不讨好
- 先分清哪几个属性是当前阶段最关键的
- 围绕关键属性做取舍，其他够用就好
# 明确「为谁牺牲谁」，架构才站得住。把最关键的两三个质量属性说清楚，架构的取舍才有依据。
ATAM：结构化找风险与权衡
ATAM 是一套经典的架构评估方法，它的核心思路不复杂：先把业务目标和质量属性讲清楚，再对着架构把用例走一遍，找出哪里有风险、哪里在做权衡。它不追求一次得出完美结论，而是让大家坐在一起，把分歧和隐患摊开。
| 步骤 | 做什么 |
|---|---|
| 讲目标 | 这个系统要服务什么业务、关键质量属性是什么 |
| 画架构 | 把当前的结构和关键决策摆出来 |
| 走用例 | 拿典型场景过一遍，看哪里脆弱 |
| 列风险 | 把发现的风险点和权衡点记录下来 |
ATAM 的价值不在于方法多精密，而在于它强制大家围绕同一个目标系统地对话，而不是各说各话。
ADR：把重要决策记下来
架构决策记录（ADR）是一页纸的小文档，专门记录某个重要决策的背景、选项、选择和理由。它不用写长，一页就够，但要留下「当时为什么这么选」。
# 一份 ADR 通常就几块内容
标题：我们决定采用 X 方案
背景：遇到了什么问题、有什么约束
可选方案：当时考虑过哪几条路
决策：最后选了哪一个
理由：为什么是它、放弃了什么
# 一页纸，足够后来人理解当初的取舍。ADR 的读者主要是三个月后的自己和同事——他们最需要知道的，往往是「为什么」。
架构演进：让改变可追溯
架构一定会随业务演进而改变。健康的演进不是推倒重来，而是每一次改动都有记录、有理由、有回退余地。旧的 ADR 被新决策推翻时，也保留下来，标注它已被什么取代。
- 重要改动先写一份新的 ADR，再动手。
- 旧决策不删除，标注它被谁替代。
- 演进历史连起来，就是一部团队的架构故事。
这样，任何时候有人问「当初为什么这么设计」，都能翻出答案，而不是靠口口相传的记忆。
让架构成为团队共同语言
架构评估与 ADR 的最终目的，是让架构不再是少数几个人脑子里的默契，而是整个团队都能读懂、能讨论、能继承的共同语言。
- 质量属性说在前面，取舍才有共同标准。
- 风险被提前摆出来，而不是上线后才发现。
- 决策被记录下来，新人也能快速理解来龙去脉。
当架构成为团队的共同语言，它就不再是一张挂在墙上的图，而是指导每一次技术决策的活的依据。