架构决策
系统性地评估架构决策、记录权衡取舍，并为具体上下文选择合适的模式。提供模式选择、ADR 创建和技术债管理的框架。
何时使用本技能
在以下情况使用本技能：
进行技术选择
评估架构模式
创建架构决策记录
评估技术债
比较设计备选方案
在以下情况不要使用本技能：
编写实现代码
处理需求（请使用 requirements-analysis）
进行完整系统设计（请使用 system-design）
核心原则
上下文驱动决策。没有普遍良好或普遍糟糕的模式。最好的架构不是最优雅的——而是最能服务其目的，同时保持可维护和可演进的那一个。
权衡三角
每个架构决策都涉及权衡：
顶点 | 通过什么方式最大化 | 代价 简单性 | 单体、同步通信、单一数据库 | 可扩展性限制 灵活性 | 微服务、事件驱动、插件 | 复杂度开销 性能 | 缓存、反规范化、优化代码 | 可维护性
平衡策略：
从简单开始，按需增加复杂度
在优化之前先度量
使用抽象来推迟决策
增量演进
质量属性
性能
指标：响应时间（p50、p95、p99）、吞吐量、资源利用率
策略：缓存、负载均衡、异步处理
可扩展性
维度：水平、垂直、弹性
模式：无状态服务、分片、事件流
可靠性
指标：正常运行时间、MTBF、MTTR
模式：断路器、重试、冗余
可维护性
因素：可读性、模块化、可测试性
模式：整洁架构、DDD、SOLID
上下文-模式映射
团队上下文
上下文 | 首选模式 | 避免 小团队 | 单体、垂直切片、共享数据库 | 微服务、复杂抽象 多团队 | 服务边界、API 契约 | 共享状态、紧耦合
规模上下文
上下文 | 首选模式 | 理由 初创 | 单体优先、垂直扩展 | 优化开发速度 企业 | 服务网格、水平扩展 | 优化运营规模
决策矩阵模板
选项 | 一致性 | 灵活性 | 可扩展性 | 复杂度 | 成本 | 合计 选项 A | 5 | 2 | 3 | 2 | 3 | 15 选项 B | 3 | 5 | 4 | 3 | 3 | 18 选项 C | 2 | 3 | 5 | 1 | 2 | 13
根据上下文优先级设置权重因子。
架构决策记录（ADR）模板
ADR-[编号]: [标题]
状态
[提议中 | 已接受 | 已弃用 | 已被取代]
上下文
[需要做出决策的情况是什么？]
需求
- [需求 1]
- [需求 2]
约束
- [约束 1]
- [约束 2]
决策
[决策是什么？]
理由
- [理由 1]
- [理由 2]
后果
正面
- [收益 1]
- [收益 2]
负面
- [缺点 1]
- [缺点 2]
考虑的备选方案
[备选方案 1]
被否决原因：[为什么]
[备选方案 2]
被否决原因：[为什么]
架构重构模式
抽象分支（Branch by Abstraction）
在当前实现之上创建抽象
在抽象背后实现新方案
切换到新实现
移除旧实现
绞杀者（Strangler Fig）
识别边界
为新功能实现新方案
逐步迁移旧功能
退役旧系统
并行运行（Parallel Run）
实现新方案
同时运行新旧方案
比较结果
在确信时切换
技术债管理
债务类别
类型 | 示例 | 偿还策略 设计 | 缺少抽象、紧耦合 | 重构冲刺 代码 | 重复、复杂、命名不佳 | 持续清理 测试 | 缺少测试、不稳定测试 | 测试改进 文档 | 缺少文档、过时图表 | 文档冲刺
指标
债务比率：债务工作 / 总工作（目标 < 20%）
利率：因债务带来的额外工作
债务上限：可接受的最大债务
反模式
大泥球（Big Ball of Mud）
症状：没有清晰结构，一切都依赖一切 补救：识别边界、提取模块、建立接口
分布式单体（Distributed Monolith）
症状：服务必须一起部署、同步链、共享数据库 补救：合并相关服务、异步通信、分离数据库
金锤子（Golden Hammer）
症状：一个方案解决所有问题、强行套用模式 补救：学习替代方案、客观评估、原型验证选项
相关技能
system-design - 带 ADR 的完整系统设计
code-review - 实现验证
task-decomposition - 拆分架构工作
requirements-analysis - 理解约束