Architecture Decision 是一个面向架构决策过程的结构化技能，用于系统化评估架构方案、记录权衡取舍，并为特定上下文选择合适的模式。它提供模式选择框架、ADR 创建和技术债管理方法。
【用途】 适合以下场景：做出技术选择；评估架构模式；创建架构决策记录；评估技术债；比较设计备选方案。不适合以下场景：编写实现代码；处理需求（应使用 requirements-analysis）；进行完整系统设计（应使用 system-design）。
【核心原则】 上下文驱动决策。没有哪个模式是普遍好或坏的。最好的架构不是最优雅的，而是在保持可维护和可演进的同时最服务其目的的架构。
【权衡三角】 每个架构决策都涉及权衡。三角包含三个顶点：简单性（通过单体、同步通信、单一数据库最大化，代价是扩展性受限）；灵活性（通过微服务、事件驱动、插件最大化，代价是复杂度开销）；性能（通过缓存、反规范化、优化代码最大化，代价是可维护性）。平衡策略包括：从简单开始，按需增加复杂度；先测量再优化；用抽象推迟决策；增量演进。
【质量属性】 性能：指标为响应时间（p50、p95、p99）、吞吐量、资源利用率；战术包括缓存、负载均衡、异步处理。可扩展性：维度包括水平、垂直、弹性；模式包括无状态服务、分片、事件流。可靠性：指标为正常运行时间、MTBF、MTTR；模式包括断路器、重试、冗余。可维护性：因素包括可读性、模块化、可测试性；模式包括整洁架构、DDD、SOLID。
【上下文与模式映射】 团队上下文：小团队优先单体、垂直切片、共享数据库，避免微服务和复杂抽象；多团队优先服务边界、API 契约，避免共享状态和紧耦合。规模上下文：初创优先单体优先、垂直扩展，为开发速度优化；企业优先服务网格、水平扩展，为运维规模优化。
【决策矩阵模板】 以表格比较各选项在一致性、灵活性、可扩展性、复杂度、成本等维度上的得分并计算总分，并根据上下文优先级设置权重因子。资料中给出 Option A/B/C 的示例分值。
【ADR 模板】 包含：编号与标题；状态（Proposed / Accepted / Deprecated / Superseded）；上下文（需要决策的情境、需求、约束）；决策（决策内容及理由）；后果（正面收益、负面缺点）；考虑的备选方案（每个备选方案及被拒绝原因）。
【架构重构模式】 抽象分支：在当前实现之上创建抽象；在抽象后实现新方案；切换到新实现；移除旧实现。绞杀者模式（Strangler Fig）：识别边界；为新功能实现新方案；逐步迁移旧功能；淘汰旧系统。并行运行：实现新方案；同时运行新旧方案；比较结果；有信心后切换。
【技术债管理】 债务类别包括：设计债（缺失抽象、紧耦合，用重构冲刺偿还）、代码债（重复、复杂、命名差，持续清理）、测试债（缺失测试、不稳定测试，测试改进）、文档债（缺失文档、过时图表，文档冲刺）。指标包括：债务比率（债务工作/总工作，目标小于 20%）、利率（因债务产生的额外工作量）、债务上限（最大可接受债务）。
【反模式】 大泥球：症状为无清晰结构、一切依赖一切；补救为识别边界、抽取模块、建立接口。分布式单体：症状为服务必须一起部署、同步调用链、共享数据库；补救为合并相关服务、异步通信、分离数据库。金锤子：症状为用同一方案解决所有问题、强行套用模式；补救为学习替代方案、客观评估、原型验证。
【相关技能】 system-design（含 ADR 的完整系统设计）、code-review（实现验证）、task-decomposition（拆分架构工作）、requirements-analysis（理解约束）。
【限制】 该资料未提供具体收费、价格、平台支持范围或实际使用步骤等信息；技能以框架和模板形式提供，具体执行需结合项目上下文。