架构决策框架

要解决什么问题

团队在「该用微服务还是单体」「事件驱动是否过度设计」这类问题上，常见两种失败：要么拍脑袋选型，事后难以解释；要么文档堆满模式名词，却缺少与当前需求绑定的权衡记录。本技能把架构工作拆成可复用的决策流程，而不是一份模式大全。

技能如何工作

入口是一句约束：只读取与请求相关的文件。通过内容映射按需打开：

• context-discovery.md：在设计开始时澄清需求、约束与项目分类
• trade-off-analysis.md：用 ADR 模板与权衡框架记录「为什么选 A 不选 B」
• pattern-selection.md：用决策树与反模式辅助选型，避免默认套用流行架构
• examples.md / patterns-reference.md：在 MVP、SaaS、企业级等场景下对照实现与模式速查

核心原则写得很直白：从简单开始，仅在证明必要时增加复杂性；重要决策应落成 ADR，并在定稿前对照验证清单（需求是否清楚、是否考虑过更简单的替代、团队能力是否匹配等）。

适用边界与注意点

它侧重决策过程与文档化，不替代具体的数据库模式、API 契约或部署拓扑——这些可与 database-design、api-patterns、deployment-procedures 等技能衔接。若你的问题只是「给我画一张架构图」而没有决策背景，应先补齐上下文再读对应章节，否则容易把模式参考误当成最终答案。