关于 architecture-decision
Architecture Decision 是面向软件团队的架构决策技能，用于比较设计方案、记录权衡并管理技术债。它强调根据具体情境选择模式，而非假定某种架构适用于所有场景。
主要功能
- 01比较架构方案
- 02按情境匹配架构模式
- 03创建架构决策记录
- 04评估质量属性
- 05记录重构方法
- 06分类并跟踪技术债
适用场景
- 01在不同架构模式间做选择
- 02记录技术选型的决策依据
- 03规划技术债处理工作
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/architecture-decision确认已加载。
详细介绍
架构决策
系统地评估架构决策、记录权衡，并针对具体情境选择合适的模式。提供模式选择、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-[NUMBER]: [TITLE]
## Status
[Proposed | Accepted | Deprecated | Superseded]
## Context
[What is the situation requiring a decision?]
### Requirements
- [Requirement 1]
- [Requirement 2]
### Constraints
- [Constraint 1]
- [Constraint 2]
## Decision
[What is the decision?]
### Justification
- [Reason 1]
- [Reason 2]
## Consequences
### Positive
- [Benefit 1]
- [Benefit 2]
### Negative
- [Drawback 1]
- [Drawback 2]
## Alternatives Considered
### [Alternative 1]
Reason rejected: [Why]
### [Alternative 2]
Reason rejected: [Why]
架构重构模式
抽象分支
- 为当前实现创建抽象层
- 在抽象层后实现新方案
- 切换到新实现
- 移除旧实现
绞杀者无花果模式
- 确定边界
- 为新功能实现新方案
- 逐步迁移旧功能
- 退役旧系统
并行运行
- 实现新方案
- 同时运行新旧方案
- 比较结果
- 确认无误后切换
技术债管理
债务类别
| 类型 | 示例 | 偿还策略 |
|---|---|---|
| 设计 | 缺少抽象、紧密耦合 | 重构冲刺 |
| 代码 | 重复、复杂、命名不佳 | 持续清理 |
| 测试 | 缺少测试、不稳定的测试 | 改进测试 |
| 文档 | 缺少文档、过时的图表 | 文档冲刺 |
指标
- 债务比率： 债务工作量 / 总工作量（目标 < 20%）
- 利息率： 因债务产生的额外工作量
- 债务上限： 可接受的最高债务
反模式
大泥球
症状： 结构不清晰，一切都相互依赖 解决方法： 明确边界，提取模块，建立接口
分布式单体
症状： 服务必须一起部署、同步调用链、共享数据库 解决方法： 合并相关服务，采用异步通信，分离数据库
金锤
症状： 所有问题都用一种方案解决，生搬硬套模式 解决方法： 了解其他方案，客观评估，制作方案原型
相关技能
- system-design - 使用 ADR 进行完整的系统设计
- code-review - 验证实现
- task-decomposition - 分解架构工作
- requirements-analysis - 理解约束条件
评论
支持 Markdown