decomposition-planning-roadmap

分解规划与路线图

此技能可创建结构化的分解计划和路线图，指导从单体架构迁移到分布式架构，并通过分解模式确定工作优先级和跟踪进度。

如何使用

快速开始

请求创建分解计划：

• “为此代码库创建分解路线图”
• “规划分解迁移策略”
• “根据组件分析确定分解工作的优先级”
• “创建分步分解计划”

使用示例

示例 1：完整路线图

User: "Create a decomposition roadmap for this codebase"

The skill will:
1. Analyze current codebase state
2. Identify decomposition patterns to apply
3. Prioritize work based on risk and value
4. Create phased roadmap
5. Generate architecture stories
6. Estimate effort and dependencies

示例 2：优先级计划

User: "Prioritize decomposition work based on component analysis"

The skill will:
1. Review component inventory and dependencies
2. Assess risk and value for each pattern
3. Prioritize patterns by impact
4. Create prioritized work plan

示例 3：阶段规划

User: "Create a phased decomposition plan"

The skill will:
1. Group decomposition patterns into phases
2. Identify dependencies between phases
3. Create phase timeline
4. Define phase success criteria

分步流程

1. 评估当前状态：分析代码库并确定已完成的工作
2. 识别模式：确定要应用哪些分解模式
3. 确定工作优先级：根据风险、价值和依赖关系排列模式
4. 创建路线图：制定包含里程碑的分阶段计划
5. 生成故事：创建用于跟踪的架构故事
6. 跟踪进度：监控各分解阶段的进展

适用场景

在以下情况下应用此技能：

• 启动分解工作
• 规划从单体架构迁移到分布式架构
• 确定分解工作的优先级
• 创建用于分解的架构故事
• 跟踪各分解模式的进展
• 需要采用结构化的分解方法
• 希望估算工作量和依赖关系

核心概念

分解模式序列

六种基于组件的分解模式应按顺序应用：

1. 识别并估算组件规模 - 了解现有组件
2. 收集通用领域组件 - 查找重复项
3. 扁平化组件 - 移除孤立类
4. 确定组件依赖关系 - 评估耦合情况
5. 创建组件领域 - 将组件归入各领域
6. 创建领域服务 - 将组件提取为服务

分阶段方法

分解通常分为以下阶段：

阶段 1：分析与准备（模式 1-4）

• 识别组件并估算规模
• 检测通用组件
• 扁平化组件
• 分析依赖关系

阶段 2：领域组织（模式 5）

• 识别领域
• 对组件进行分组
• 重构命名空间

阶段 3：提取服务（模式 6）

• 创建领域服务
• 提取服务
• 定义 API 边界

优先级因素

确定分解工作的优先级时，请考虑：

• 风险：风险低意味着更易于提取，依赖关系也更少
• 价值：价值高意味着对业务至关重要、影响较大
• 依赖关系：是否可以独立完成这项工作？
• 复杂度：越简单，组件越少、边界越清晰
• 耦合度：耦合度越低，越容易提取

分析流程

阶段 1：评估当前状态

分析已完成的工作：

1. 检查组件清单

   • 是否已识别组件并估算规模？
   • 是否有组件清单文档？
   • 是否已识别规模过大的组件？

2. 检查通用组件分析

   • 是否已识别通用领域组件？
   • 是否已记录整合机会？
   • 是否已分析耦合影响？

3. 检查组件结构

   • 是否已扁平化组件？
   • 是否存在孤立类？
   • 组件结构是否清晰？

4. 检查依赖关系分析

   • 是否已绘制组件依赖关系图？
   • 耦合分析是否已完成？
   • 是否已评估可行性？

5. 检查领域识别

   • 是否已识别领域？
   • 是否已将组件归入各领域？
   • 命名空间是否与领域保持一致？

6. 检查服务提取

   • 是否已提取任何服务？
   • 是否已创建领域服务？
   • 是否已采用基于服务的架构？

输出：当前状态评估，说明已完成和剩余的工作

Phase 2：确定要应用的模式

确定需要应用哪些分解模式：

1. 检查模式的前置条件

   • 模式 1：始终需要（基础）
   • 模式 2：存在通用组件时需要
   • 模式 3：组件存在层级结构时需要
   • 模式 4：始终需要（可行性检查）
   • 模式 5：提取服务前需要
   • 模式 6：最后一步（提取服务）

2. 检查模式的完成情况

   • 哪些模式已完成？
   • 哪些模式正在进行？
   • 哪些模式尚未开始？

3. 确定缺失的模式

   • 还需要应用哪些模式？
   • 什么因素阻碍了模式的应用？
   • 存在哪些依赖项？

输出：待应用模式列表及其状态

Phase 3：确定工作优先级

确定分解模式和工作项的优先级：

1. 评估风险

   • 低风险：基础设施组件、独立功能
   • 中风险：存在一些依赖项的领域组件
   • 高风险：核心业务逻辑、高耦合

2. 评估价值

   • 高价值：对业务至关重要、影响大、变更频繁
   • 中价值：重要但并非关键
   • 低价值：锦上添花、影响小

3. 评估依赖关系

   • 独立：无需其他工作即可完成
   • 依赖：需要先完成其他模式/工作
   • 阻塞：阻碍其他工作继续推进

4. 计算优先级得分

   Priority = (Value × 3) - (Risk × 2) - (Dependencies × 1)
   
   Higher score = Higher priority
   

输出：按优先级排列的模式和工作项列表

Phase 4：制定分阶段路线图

制定包含里程碑的分阶段路线图：

1. 定义阶段

   • 阶段 1：分析与准备
   • 阶段 2：领域组织
   • 阶段 3：提取服务
   • 阶段 4：优化与完善

2. 为各阶段分配模式

   • 哪些模式属于哪个阶段？
   • 每个阶段内的顺序是什么？
   • 阶段之间有哪些依赖关系？

3. 设定里程碑

   • 什么标志着各阶段的完成？
   • 成功标准是什么？
   • 预期交付成果是什么？

4. 估算时间线

   • 每个阶段需要多长时间？
   • 存在哪些依赖关系？
   • 关键路径是什么？

输出：包含时间线和里程碑的分阶段路线图

Phase 5：生成架构故事

创建用于跟踪工作的架构故事：

1. 创建故事模板

   As an architect, I need to [apply pattern/refactor component]
   to support [architectural characteristic/business need]
   so that [benefit/outcome]
   

2. 拆分工作

   • 每项模式应用创建一个故事
   • 每项重大重构创建一个故事
   • 每个领域分组创建一个故事

3. 添加验收标准

   • 什么条件定义了“完成”？
   • 哪些指标可验证成功？
   • 哪些测试可验证完成情况？

4. 估算工作量

   • 故事点或时间估算
   • 复杂度评估
   • 风险因素

输出：包含估算的架构故事列表

Phase 6：跟踪进度

监控分解工作的进度：

1. 跟踪模式完成情况

   • 哪些模式已完成？
   • 哪些正在进行？
   • 哪些受阻？

2. 跟踪故事完成情况

   • 已完成的故事
   • 正在进行的故事
   • 尚未开始的故事

3. 跟踪指标

   • 已识别的组件
   • 已重构的组件
   • 已创建的领域
   • 已提取的服务

4. 确定阻碍因素

   • 什么因素阻碍了进度？
   • 缺少哪些依赖项？
   • 出现了哪些风险？

输出：进度仪表板和状态报告

输出格式

分解路线图

# Decomposition Roadmap

## Current State Assessment

**Completed Patterns**:

- ✅ Pattern 1: Identify and Size Components
- ✅ Pattern 2: Gather Common Domain Components
- ⚠️ Pattern 3: Flatten Components (in progress)
- ❌ Pattern 4: Determine Component Dependencies (not started)
- ❌ Pattern 5: Create Component Domains (not started)
- ❌ Pattern 6: Create Domain Services (not started)

**Key Findings**:

- 75 components identified
- 3 common domain components found
- 2 oversized components need splitting
- High database coupling detected

## Phased Roadmap

### Phase 1: Analysis & Preparation (Weeks 1-4)

**Goal**: Complete component analysis and refactoring

**Patterns**:

1. Complete Pattern 3: Flatten Components
2. Apply Pattern 4: Determine Component Dependencies
3. Refactor oversized components

**Milestones**:

- Week 2: Component flattening complete
- Week 4: Dependency analysis complete

**Deliverables**:

- Flattened component structure
- Dependency diagram
- Feasibility assessment

### Phase 2: Domain Organization (Weeks 5-8)

**Goal**: Organize components into domains

**Patterns**:

1. Apply Pattern 5: Create Component Domains
2. Refactor namespaces for domain alignment

**Milestones**:

- Week 6: Domains identified
- Week 8: Namespace refactoring complete

**Deliverables**:

- Domain map
- Refactored component namespaces
- Domain documentation

### Phase 3: Service Extraction (Weeks 9-16)

**Goal**: Extract domains to domain services

**Patterns**:

1. Apply Pattern 6: Create Domain Services
2. Extract services incrementally

**Milestones**:

- Week 12: First domain service extracted
- Week 16: All domain services extracted

**Deliverables**:

- Domain services deployed
- API boundaries defined
- Service documentation

按优先级排列的工作计划

## Prioritized Work Plan

### High Priority (Do First)

1. **Complete Component Flattening** (Priority: 9/10)
   - Risk: Low
   - Value: High (enables domain grouping)
   - Dependencies: None
   - Effort: 2 weeks

2. **Dependency Analysis** (Priority: 8/10)
   - Risk: Low
   - Value: High (validates feasibility)
   - Dependencies: Component flattening
   - Effort: 1 week

### Medium Priority (Do Next)

3. **Domain Identification** (Priority: 7/10)
   - Risk: Medium
   - Value: High (enables service extraction)
   - Dependencies: Dependency analysis
   - Effort: 2 weeks

### Low Priority (Do Later)

4. **Service Extraction** (Priority: 5/10)
   - Risk: High
   - Value: High (final goal)
   - Dependencies: Domain identification
   - Effort: 8 weeks

架构故事

## Architecture Stories

### Story 1: Flatten Ticket Components

**As an architect**, I need to flatten the Ticket component hierarchy
to support better component organization
so that components exist only as leaf nodes.

**Acceptance Criteria**:

- [ ] No orphaned classes in root namespaces
- [ ] All components are leaf nodes
- [ ] Component structure validated

**Estimate**: 5 story points
**Priority**: High
**Dependencies**: None

### Story 2: Identify Component Domains

**As an architect**, I need to group components into logical domains
to support service-based architecture
so that components can be extracted to domain services.

**Acceptance Criteria**:

- [ ] All components assigned to domains
- [ ] Domain boundaries validated with stakeholders
- [ ] Domain map created

**Estimate**: 8 story points
**Priority**: High
**Dependencies**: Component flattening complete

进度仪表板

## Decomposition Progress Dashboard

### Pattern Completion Status

| Pattern                    | Status         | Progress | Blocker                 |
| -------------------------- | -------------- | -------- | ----------------------- |
| Identify & Size Components | ✅ Complete    | 100%     | None                    |
| Gather Common Components   | ✅ Complete    | 100%     | None                    |
| Flatten Components         | ⚠️ In Progress | 60%      | None                    |
| Determine Dependencies     | ❌ Not Started | 0%       | Waiting on flattening   |
| Create Domains             | ❌ Not Started | 0%       | Waiting on dependencies |
| Create Domain Services     | ❌ Not Started | 0%       | Waiting on domains      |

### Story Completion Status

**Completed**: 5 stories (25%)
**In Progress**: 3 stories (15%)
**Not Started**: 12 stories (60%)

### Key Metrics

- Components Identified: 75
- Components Refactored: 45 (60%)
- Domains Created: 0
- Services Extracted: 0

分析检查清单

当前状态评估：

• 已查看组件清单
• 已检查通用组件分析
• 已评估组件结构
• 已查看依赖关系分析
• 已检查领域识别
• 已评估服务提取状态

模式识别：

• 已识别已完成的模式
• 已识别正在进行的模式
• 已识别需要应用的模式
• 已检查模式依赖关系

优先级排序：

• 已评估每种模式的风险
• 已评估每种模式的价值
• 已评估依赖关系
• 已计算优先级分数

路线图制定：

• 已定义阶段
• 已将模式分配到各阶段
• 已设定里程碑
• 已估算时间表

故事生成：

• 已创建架构故事
• 已添加验收标准
• 已估算工作量
• 已为故事排序

进度跟踪：

• 已设置跟踪机制
• 已定义指标
• 已创建仪表板
• 已识别阻碍因素

实施说明

路线图模板

简单路线图（适用于小型项目）：

• 阶段 1：分析（2-4 周）
• 阶段 2：重构（4-6 周）
• 阶段 3：提取（8-12 周）

详细路线图（适用于大型项目）：

• 阶段 1：分析与准备（4-8 周）
• 阶段 2：领域组织（4-6 周）
• 阶段 3：服务提取（12-16 周）
• 阶段 4：优化（4-8 周）

优先级矩阵

使用 2x2 矩阵进行优先级排序：

High Value, Low Risk    | High Value, High Risk
(Do First)              | (Do Carefully)
────────────────────────┼──────────────────────
Low Value, Low Risk     | Low Value, High Risk
(Do Later)              | (Avoid/Defer)

故事估算

使用故事点数或时间估算：

故事点数（斐波那契数列）：

• 1：琐碎（数小时）
• 2：简单（1 天）
• 3：较小（2-3 天）
• 5：中等（1 周）
• 8：较大（2 周）
• 13：非常大（3 周以上）

时间估算：

• 较小：1-3 天
• 中等：1-2 周
• 较大：2-4 周
• 非常大：1 个月以上

最佳实践

应该 ✅

• 从分析模式（模式 1-4）开始
• 优先处理低风险、高价值的工作
• 创建架构故事以跟踪进度
• 设定明确的里程碑和成功标准
• 定期跟踪进度
• 根据经验调整路线图
• 与利益相关方协作确定优先级

不应该 ❌

• 不要跳过分析模式
• 不要过早开始提取服务
• 不要忽略模式之间的依赖关系
• 不要制定不切实际的时间表
• 不要跳过进度跟踪
• 不要忘记与利益相关方确认
• 不要在未评估可行性的情况下继续推进

与其他技能的集成

此技能协调使用其他分解技能：

1. 组件识别与规模评估 → 规划基础
2. 通用领域组件检测 → 识别整合工作
3. 组件扁平化 → 为领域分组做准备
4. 组件依赖关系分析 → 验证可行性
5. 领域识别与分组 → 支持服务提取
6. 分解规划与路线图（此技能）→ 协调所有工作

后续步骤

创建路线图后：

1. 与利益相关方评审 - 获得对计划的认可
2. 开始阶段 1 - 从分析模式入手
3. 跟踪进度 - 监控完成情况和阻碍因素
4. 按需调整 - 根据经验更新路线图
5. 庆祝里程碑 - 肯定取得的进展

备注

• 路线图应是持续更新的文档，定期维护
• 随着了解不断深入，优先级可能会改变
• 必须遵循模式之间的依赖关系
• 推进前进行可行性评估至关重要
• 与利益相关方协作是成功的关键
• 跟踪进度有助于及早发现问题