架构选择与适应性检查 是做什么的？
将目标转化为可观察的行为
识别参与者、关键工作流、数据所有权和约束条件。将“可扩展”、“安全”和“可维护”转换为具体场景：刺激→环境→响应→度量。对实质上决定设计的少数特性进行排序。区分强制性约束与偏好。
流程
- 与利益相关方共同定义质量场景和验收阈值。说明工作负载、故障和团队假设。参考选择指南。
- 确定每个属性必须成立的范围：组件、部署、工作流或整个系统。不同部分可能适合不同的风格。
- 将一小部分可行的风格（包括模块化单次部署）与这些场景进行比较。解释支持每个声称的收益的机制。
- 检查耦合度：源码依赖、运行时调用、共享数据和协调变更。静态的模块独立性并不能证明运行时的故障隔离。
- 选择最简单的可行风格，并记录ADR、后果以及重新考虑的触发条件。将可逆的实现细节与代价高昂的结构性承诺分开。
- 将关键决策转化为适应性检查：禁止的依赖关系、契约兼容性、延迟预算、恢复时间和租户隔离。参考适应性检查。
- 在观察到的负载和变更模式下重新评估。通过一项依赖规则只是某个属性的证据，并不代表整体架构质量。
评审问题
- 插件边界是否解决了实际的可扩展性需求，同时没有让每个插件无限制地访问核心？
- 事件是否需要持久化发布、模式兼容性、去重和延迟监控？这些成本是否已包含在事件驱动提案中？
- 独立部署是否改善了某个度量的瓶颈或释放了约束？
- 提议的团队能否处理由此产生的部署和故障复杂性？
- 当数据所有权分离时，哪个不变量变得更难保持？
输出
返回质量场景、候选机制/权衡、所选结构、所有权/依赖映射、ADR、适应性检查和未解决的假设。
范围与参考文献
部分覆盖了《软件架构基础》第二版（Richards和Ford）的内容。本原始指南基于作者资料、公开的作者访谈记录、出版商内容和架构测试文档。参见来源。没有一种风格是通用的成熟阶段。