架构决策必须记录目标约束与取舍
来源整理卡：基于原图提炼，尚未补充独立官方资料和环境实测。
核心认识
架构图需要连接业务目标、非功能约束、故障域、成本和决策依据。
解释
原图指出只画组件不画流量、没有约束和追逐热点等问题，并引入 ADR、数据流与风险清单。卡片应保存当时为何选择，而不只是最终用了什么。
什么时候使用
选型、架构评审或后来需要推翻既有决策时。
边界
这是思考与取证原则，不证明某次故障根因，也不授权执行修改。具体参数和组件行为仍要依据版本与环境核验。
用一个问题检查是否真正理解
关键场景是什么，舍弃了哪些备选方案，决定依赖哪些假设？
原图依据
- 把业务目标、可靠性、数据、安全、成本转成可评审架构。
原图知识项：
- functional/non-functional
- SLO/capacity/security
- failure domains
- build vs buy
- ADR
- evolutionary architecture
有意义的关联
先从 架构与容量 找到使用场景；需要进一步查命令、风险或练习时，进入 需求、约束与架构决策。
来源：原图节点。