名称: 分解规划路线图 描述: 为迁移单体应用创建结构化分解计划和路线图。用于规划分解、创建迁移路线图、优先处理分解工作、跟踪分解进度，或当用户询问分解规划、迁移策略或架构路线图时使用。
分解规划与路线图
此技能创建结构化分解计划和路线图，以指导从单体到分布式架构的迁移，通过分解模式优先处理工作并跟踪进度。
如何使用
快速开始
请求创建分解计划：
- “为此代码库创建分解路线图”
- “规划分解迁移策略”
- “基于组件分析优先处理分解工作”
- “创建分步分解计划”
使用示例
示例 1：完整路线图
用户: “为此代码库创建分解路线图”
此技能将：
1. 分析当前代码库状态
2. 识别要应用的分解模式
3. 基于风险和价值优先处理工作
4. 创建分阶段路线图
5. 生成架构故事
6. 估计工作量和依赖关系
示例 2：优先级计划
用户: “基于组件分析优先处理分解工作”
此技能将：
1. 审查组件清单和依赖关系
2. 评估每个模式的风险和价值
3. 按影响优先处理模式
4. 创建优先工作计划
示例 3：阶段规划
用户: “创建分阶段分解计划”
此技能将：
1. 将分解模式分组到阶段
2. 识别阶段间的依赖关系
3. 创建阶段时间线
4. 定义阶段成功标准
分步流程
- 评估当前状态：分析代码库并识别已完成的内容
- 识别模式：确定要应用的分解模式
- 优先处理工作：按风险、价值和依赖关系排序模式
- 创建路线图：构建带有里程碑的分阶段计划
- 生成故事：创建用于跟踪的架构故事
- 跟踪进度：通过分解阶段监控进度
何时使用
应用此技能当：
- 开始分解工作
- 规划从单体到分布式架构的迁移
- 优先处理分解工作
- 为分解创建架构故事
- 通过分解模式跟踪进度
- 需要结构化的分解方法
- 想要估计工作量和依赖关系
核心概念
分解模式序列
六个基于组件的分解模式应按顺序应用：
- 识别和大小组件 – 了解现有内容
- 收集公共领域组件 – 查找重复项
- 扁平化组件 – 移除孤立类
- 确定组件依赖关系 – 评估耦合度
- 创建组件域 – 分组到域中
- 创建域服务 – 提取为服务
分阶段方法
分解通常遵循阶段：
阶段 1：分析与准备（模式 1-4）
- 组件识别和大小调整
- 公共组件检测
- 组件扁平化
- 依赖分析
阶段 2：域组织（模式 5）
- 域识别
- 组件分组
- 命名空间重构
阶段 3：服务提取（模式 6）
- 域服务创建
- 服务提取
- API边界定义
优先级因素
当优先处理分解工作时，考虑：
- 风险：低风险 = 更容易提取，更少依赖关系
- 价值：高价值 = 业务关键，高影响
- 依赖关系：能否独立完成？
- 复杂性：简单 = 较少组件，清晰边界
- 耦合度：低耦合 = 更容易提取
分析流程
阶段 1：评估当前状态
分析已完成内容：
-
检查组件清单
- 组件是否已识别和大小调整？
- 是否有组件清单文档？
- 超大组件是否已识别？
-
检查公共组件分析
- 公共领域组件是否已识别？
- 是否记录了合并机会？
- 是否分析了耦合影响？
-
检查组件结构
- 组件是否已扁平化？
- 是否有孤立类？
- 组件结构是否干净？
-
检查依赖分析
- 组件依赖关系是否已映射？
- 耦合分析是否完成？
- 是否评估了可行性？
-
检查域识别
- 域是否已识别？
- 组件是否分组到域中？
- 命名空间是否与域对齐？
-
检查服务提取
- 是否有任何服务已提取？
- 是否创建了域服务？
- 是否实现了基于服务的架构？
输出：当前状态评估，显示已完成和剩余内容
阶段 2：识别要应用的模式
确定需要应用的分解模式：
-
审查模式先决条件
- 模式 1：始终需要（基础）
- 模式 2：如果存在公共组件则需
- 模式 3：如果组件有层次结构则需
- 模式 4：始终需要（可行性检查）
- 模式 5：服务提取前需要
- 模式 6：最终步骤（服务提取）
-
检查模式完成度
- 哪些模式已完成？
- 哪些模式进行中？
- 哪些模式未开始？
-
识别缺失模式
- 哪些模式仍需应用？
- 什么阻止了模式应用？
- 存在哪些依赖关系？
输出：带状态的要应用模式列表
阶段 3：优先处理工作
优先处理分解模式和工作项：
-
评估风险
- 低风险：基础设施组件，独立功能
- 中风险：带一些依赖关系的域组件
- 高风险：核心业务逻辑，高耦合
-
评估价值
- 高价值：业务关键，高影响，频繁更改
- 中价值：重要但不关键
- 低价值：可有可无，低影响
-
评估依赖关系
- 独立：无需其他工作即可完成
- 依赖：需要其他模式/工作先行
- 阻塞：阻止其他工作进行
-
计算优先级分数
优先级 = (价值 × 3) - (风险 × 2) - (依赖关系 × 1) 分数越高 = 优先级越高
输出：优先处理的模式和工作项列表
阶段 4：创建分阶段路线图
构建带有里程碑的分阶段路线图：
-
定义阶段
- 阶段 1：分析与准备
- 阶段 2：域组织
- 阶段 3：服务提取
- 阶段 4：优化与改进
-
分配模式到阶段
- 哪些模式属于哪个阶段？
- 每个阶段内的序列是什么？
- 阶段间的依赖关系是什么？
-
设置里程碑
- 什么标志着每个阶段的完成？
- 成功标准是什么？
- 预期可交付成果是什么？
-
估计时间线
- 每个阶段需要多长时间？
- 依赖关系是什么？
- 关键路径是什么？
输出：带时间线和里程碑的分阶段路线图
阶段 5：生成架构故事
为跟踪工作创建架构故事：
-
创建故事模板
作为架构师，我需要[应用模式/重构组件] 以支持[架构特性/业务需求] 以便[益处/结果] -
分解工作
- 每个模式应用一个故事
- 每个重大重构一个故事
- 每个域分组一个故事
-
添加验收标准
- 什么定义了“完成”？
- 哪些指标验证成功？
- 哪些测试验证完成？
-
估计工作量
- 故事点或时间估计
- 复杂性评估
- 风险因素
输出：带估计的架构故事列表
阶段 6：跟踪进度
通过分解监控进度：
-
跟踪模式完成度
- 哪些模式已完成？
- 哪些进行中？
- 哪些被阻塞？
-
跟踪故事完成度
- 已完成的故事
- 进行中的故事
- 未开始的故事
-
跟踪指标
- 已识别的组件
- 已重构的组件
- 创建的域
- 提取的服务
-
识别阻塞因素
- 什么阻塞了进度？
- 缺少什么依赖关系？
- 出现了什么风险？
输出：进度仪表板和状态报告
输出格式
分解路线图
# 分解路线图
## 当前状态评估
**已完成模式**：
- ✅ 模式 1：识别和大小组件
- ✅ 模式 2：收集公共领域组件
- ⚠️ 模式 3：扁平化组件（进行中）
- ❌ 模式 4：确定组件依赖关系（未开始）
- ❌ 模式 5：创建组件域（未开始）
- ❌ 模式 6：创建域服务（未开始）
**关键发现**：
- 75 个组件已识别
- 3 个公共领域组件发现
- 2 个超大组件需要拆分
- 检测到高数据库耦合
## 分阶段路线图
### 阶段 1：分析与准备（第 1-4 周）
**目标**：完成组件分析和重构
**模式**：
1. 完成模式 3：扁平化组件
2. 应用模式 4：确定组件依赖关系
3. 重构超大组件
**里程碑**：
- 第 2 周：组件扁平化完成
- 第 4 周：依赖分析完成
**可交付成果**：
- 扁平化组件结构
- 依赖图
- 可行性评估
### 阶段 2：域组织（第 5-8 周）
**目标**：将组件组织到域中
**模式**：
1. 应用模式 5：创建组件域
2. 为域对齐重构命名空间
**里程碑**：
- 第 6 周：域已识别
- 第 8 周：命名空间重构完成
**可交付成果**：
- 域地图
- 重构的组件命名空间
- 域文档
### 阶段 3：服务提取（第 9-16 周）
**目标**：将域提取为域服务
**模式**：
1. 应用模式 6：创建域服务
2. 逐步提取服务
**里程碑**：
- 第 12 周：第一个域服务提取
- 第 16 周：所有域服务提取
**可交付成果**：
- 部署的域服务
- 定义的 API 边界
- 服务文档
优先工作计划
## 优先工作计划
### 高优先级（首先执行）
1. **完成组件扁平化**（优先级：9/10）
- 风险：低
- 价值：高（启用域分组）
- 依赖关系：无
- 工作量：2 周
2. **依赖分析**（优先级：8/10）
- 风险：低
- 价值：高（验证可行性）
- 依赖关系：组件扁平化
- 工作量：1 周
### 中优先级（接下来执行）
3. **域识别**（优先级：7/10）
- 风险：中
- 价值：高（启用服务提取）
- 依赖关系：依赖分析
- 工作量：2 周
### 低优先级（稍后执行）
4. **服务提取**（优先级：5/10）
- 风险：高
- 价值：高（最终目标）
- 依赖关系：域识别
- 工作量：8 周
架构故事
## 架构故事
### 故事 1：扁平化票务组件
**作为架构师**，我需要扁平化票务组件层次结构
以支持更好的组件组织
以便组件仅作为叶节点存在。
**验收标准**：
- [ ] 根命名空间中无孤立类
- [ ] 所有组件都是叶节点
- [ ] 组件结构已验证
**估计**：5 故事点
**优先级**：高
**依赖关系**：无
### 故事 2：识别组件域
**作为架构师**，我需要将组件分组到逻辑域中
以支持基于服务的架构
以便组件可以提取为域服务。
**验收标准**：
- [ ] 所有组件分配到域
- [ ] 与利益相关者验证域边界
- [ ] 创建域地图
**估计**：8 故事点
**优先级**：高
**依赖关系**：组件扁平化完成
进度仪表板
## 分解进度仪表板
### 模式完成状态
| 模式 | 状态 | 进度 | 阻塞因素 |
| -------------------------- | -------------- | -------- | ----------------------- |
| 识别与大小组件 | ✅ 完成 | 100% | 无 |
| 收集公共组件 | ✅ 完成 | 100% | 无 |
| 扁平化组件 | ⚠️ 进行中 | 60% | 无 |
| 确定依赖关系 | ❌ 未开始 | 0% | 等待扁平化 |
| 创建域 | ❌ 未开始 | 0% | 等待依赖关系 |
| 创建域服务 | ❌ 未开始 | 0% | 等待域 |
### 故事完成状态
**已完成**：5 个故事（25%）
**进行中**：3 个故事（15%）
**未开始**：12 个故事（60%）
### 关键指标
- 已识别组件：75
- 已重构组件：45（60%）
- 创建域：0
- 提取服务：0
分析检查清单
当前状态评估：
- [ ] 审查组件清单
- [ ] 检查公共组件分析
- [ ] 评估组件结构
- [ ] 审查依赖分析
- [ ] 检查域识别
- [ ] 评估服务提取状态
模式识别：
- [ ] 识别哪些模式已完成
- [ ] 识别哪些模式进行中
- [ ] 识别哪些模式需要应用
- [ ] 检查模式依赖关系
优先级处理：
- [ ] 评估每个模式的风险
- [ ] 评估每个模式的价值
- [ ] 评估依赖关系
- [ ] 计算优先级分数
路线图创建：
- [ ] 定义阶段
- [ ] 分配模式到阶段
- [ ] 设置里程碑
- [ ] 估计时间线
故事生成：
- [ ] 创建架构故事
- [ ] 添加验收标准
- [ ] 估计工作量
- [ ] 优先处理故事
进度跟踪：
- [ ] 设置跟踪机制
- [ ] 定义指标
- [ ] 创建仪表板
- [ ] 识别阻塞因素
实施说明
路线图模板
简单路线图（适用于小项目）：
- 阶段 1：分析（2-4 周）
- 阶段 2：重构（4-6 周）
- 阶段 3：提取（8-12 周）
详细路线图（适用于大项目）：
- 阶段 1：分析与准备（4-8 周）
- 阶段 2：域组织（4-6 周）
- 阶段 3：服务提取（12-16 周）
- 阶段 4：优化（4-8 周）
优先级矩阵
使用 2x2 矩阵进行优先级处理：
高价值，低风险 | 高价值，高风险
（首先执行） | （谨慎执行）
────────────────────────┼──────────────────────
低价值，低风险 | 低价值，高风险
（稍后执行） | （避免/推迟）
故事估计
使用故事点或时间估计：
故事点（斐波那契）：
- 1：琐碎（几小时）
- 2：简单（1 天）
- 3：小（2-3 天）
- 5：中（1 周）
- 8：大（2 周）
- 13：非常大（3+ 周）
时间估计：
- 小：1-3 天
- 中：1-2 周
- 大：2-4 周
- 非常大：1+ 月
最佳实践
该做的事 ✅
- 从分析模式开始（模式 1-4）
- 优先处理低风险、高价值工作
- 创建用于跟踪的架构故事
- 设置清晰的里程碑和成功标准
- 定期跟踪进度
- 基于学习调整路线图
- 与利益相关者协作确定优先级
不该做的事 ❌
- 不要跳过分析模式
- 不要过早开始服务提取
- 不要忽略模式间的依赖关系
- 不要创建不切实际的时间线
- 不要跳过进度跟踪
- 不要忘记与利益相关者验证
- 不要在没有可行性评估的情况下进行
与其他技能集成
此技能协调其他分解技能的使用：
- 组件识别与大小调整 → 规划的基础
- 公共领域组件检测 → 识别合并工作
- 组件扁平化 → 为域分组做准备
- 组件依赖分析 → 验证可行性
- 域识别与分组 → 启用服务提取
- 分解规划与路线图（此技能） → 协调一切
后续步骤
创建路线图后：
- 与利益相关者审查 – 获得计划支持
- 开始阶段 1 – 从分析模式开始
- 跟踪进度 – 监控完成度和阻塞因素
- 根据需要调整 – 基于学习更新路线图
- 庆祝里程碑 – 认可进展
注释
- 路线图应为活动文档，定期更新
- 优先级可能随学习更多而改变
- 必须尊重模式间的依赖关系
- 可行性评估在进行前至关重要
- 利益相关者协作对成功至关重要
- 进度跟踪有助于早期发现问题