Software Architect · 模块 21
架构不存在于真空里。它必须帮助产品赚钱、降低风险、并以合适的速度前进。
Business value · cost · risk · optionality · roadmap
一个好的技术决策必须有业务意义：速度、可靠性、风险下降、成本节省，或一种新的能力。
架构的代价必须是可见的
盖一栋楼的预算不只是砖块，还包括维护、维修、保险和停工损失。
Total cost of ownership 涵盖开发、运维、支持、培训、迁移、vendor lock-in、incident response 和 opportunity cost。一个决策可以"建造便宜，运行昂贵"。
架构师要把技术上的 trade-offs 翻译成 business terms："这种集成上线快一个月，但每周多出 10 小时的人工支持"，或者"这次 refactor 把丢失支付的风险降下来了"。
Optionality 是有价格的
你可以把房子盖成将来能加第二层。但加固过的地基现在就要花钱。
有时候，架构是在买 future optionality：进入新区域的能力、加上 enterprise SSO 的能力、切换 payment provider 的能力、扩大团队的能力。当未来场景的概率和价值足够高时，这笔钱才值得花。
差的 optionality 是"以防万一"的抽象。好的 optionality 是为一个大概率会出现的业务场景，事先准备好迁移路径。
架构师帮助产品不要把技术上的漂亮与经济上的效果混为一谈。
例子：先不做 multi-region
一家店在搞清楚第一个城市的需求之前，不会先去搭跨国物流。
创业公司从一个区域起步，但把 data model 设计成将来可以加 region 字段和 data residency。Multi-region deployment 现在不做，因为还没有 enterprise 客户。ADR 记下触发条件：第一份带 data residency requirement 的合同。
这是一个健康的平衡：现在不多花钱，也不堵死增长的路径。
反例：没有 product narrative 的 refactor
把车间地砖换一换可以。但如果机器停产一个月，你得告诉业务方，这换来的是什么。
团队要一个季度做 rewrite，理由是"代码不好"。业务方听到的是 roadmap 停摆而看不到明显回报。如果说不清这与 cycle time、incident rate、hiring、compliance 或 revenue 有什么关系，这就只像是工程师自己的愿望。
技术改进必须挂钩到一个可度量的 product 或 operational outcome。
- 这个决策买到的是哪一项 business property？ - 全生命周期的拥有成本是多少？ - 下降的是哪种风险，这种风险有多真实？ - 我要怎么不带技术细节地解释这个决策？