Back to Details

decomposition-planning-roadmap

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Decomposition Planning and Roadmap

分解规划与路线图

This skill creates structured decomposition plans and roadmaps to guide the migration from monolithic to distributed architectures, prioritizing work and tracking progress through decomposition patterns.
本技能可创建结构化的分解计划和路线图，指导从单体架构到分布式架构的迁移，通过分解模式对工作进行优先级排序并跟踪进度。

How to Use

使用方法

Quick Start

快速开始

Request creation of a decomposition plan:
  • "Create a decomposition roadmap for this codebase"
  • "Plan the decomposition migration strategy"
  • "Prioritize decomposition work based on component analysis"
  • "Create a step-by-step decomposition plan"
请求创建分解计划：
  • "为该代码库创建分解路线图"
  • "规划分解迁移策略"
  • "基于组件分析对分解工作排序优先级"
  • "创建分步分解计划"

Usage Examples

使用示例

Example 1: Complete Roadmap
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
Example 2: Prioritized Plan
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
Example 3: Phase Planning
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：完整路线图
用户: "为该代码库创建分解路线图"

本技能将：
1. 分析当前代码库状态
2. 确定要应用的分解模式
3. 基于风险和价值对工作排序优先级
4. 创建分阶段路线图
5. 生成架构需求故事
6. 评估工作量和依赖关系
示例2：优先级计划
用户: "基于组件分析对分解工作排序优先级"

本技能将：
1. 审核组件清单和依赖关系
2. 评估每种模式的风险和价值
3. 按影响程度对模式排序优先级
4. 创建优先级工作计划
示例3：阶段规划
用户: "创建分阶段分解计划"

本技能将：
1. 将分解模式分组到不同阶段
2. 确定阶段之间的依赖关系
3. 创建阶段时间线
4. 定义阶段成功标准

Step-by-Step Process

分步流程

  1. Assess Current State: Analyze codebase and identify what's been done
  2. Identify Patterns: Determine which decomposition patterns to apply
  3. Prioritize Work: Rank patterns by risk, value, and dependencies
  4. Create Roadmap: Build phased plan with milestones
  5. Generate Stories: Create architecture stories for tracking
  6. Track Progress: Monitor progress through decomposition phases
  1. 评估当前状态：分析代码库并确定已完成的工作
  2. 识别模式：确定要应用的分解模式
  3. 工作优先级排序：按风险、价值和依赖关系对模式排序
  4. 创建路线图：构建包含里程碑的分阶段计划
  5. 生成需求故事：创建用于跟踪的架构需求故事
  6. 跟踪进度：通过分解阶段监控进度

When to Use

适用场景

Apply this skill when:
  • Starting a decomposition effort
  • Planning migration from monolith to distributed architecture
  • Prioritizing decomposition work
  • Creating architecture stories for decomposition
  • Tracking progress through decomposition patterns
  • Need structured approach to decomposition
  • Want to estimate effort and dependencies
在以下场景中应用本技能：
  • 启动分解工作时
  • 规划从单体到分布式架构的迁移时
  • 对分解工作排序优先级时
  • 为分解创建架构需求故事时
  • 通过分解模式跟踪进度时
  • 需要结构化的分解方法时
  • 想要评估工作量和依赖关系时

Core Concepts

核心概念

Decomposition Pattern Sequence

分解模式序列

The six component-based decomposition patterns should be applied in sequence:
  1. Identify and Size Components - Understand what you have
  2. Gather Common Domain Components - Find duplicates
  3. Flatten Components - Remove orphaned classes
  4. Determine Component Dependencies - Assess coupling
  5. Create Component Domains - Group into domains
  6. Create Domain Services - Extract to services
应按顺序应用六种基于组件的分解模式：
  1. 识别并确定组件规模 - 了解现有组件情况
  2. 收集通用领域组件 - 查找重复组件
  3. 扁平化组件 - 移除孤立类
  4. 确定组件依赖关系 - 评估耦合度
  5. 创建组件领域 - 按领域分组
  6. 创建领域服务 - 提取为服务

Phased Approach

分阶段方法

Decomposition typically follows phases:
Phase 1: Analysis & Preparation (Patterns 1-4)
  • Component identification and sizing
  • Common component detection
  • Component flattening
  • Dependency analysis
Phase 2: Domain Organization (Pattern 5)
  • Domain identification
  • Component grouping
  • Namespace refactoring
Phase 3: Service Extraction (Pattern 6)
  • Domain service creation
  • Service extraction
  • API boundary definition
分解通常遵循以下阶段：
阶段1：分析与准备（模式1-4）
  • 组件识别与规模确定
  • 通用组件检测
  • 组件扁平化
  • 依赖关系分析
阶段2：领域组织（模式5）
  • 领域识别
  • 组件分组
  • 命名空间重构
阶段3：服务提取（模式6）
  • 领域服务创建
  • 服务提取
  • API边界定义

Prioritization Factors

优先级考量因素

When prioritizing decomposition work, consider:
  • Risk: Low risk = easier to extract, fewer dependencies
  • Value: High value = business-critical, high impact
  • Dependencies: Can this be done independently?
  • Complexity: Simple = fewer components, clear boundaries
  • Coupling: Low coupling = easier to extract
对分解工作排序优先级时，需考虑：
  • 风险：低风险 = 易于提取，依赖少
  • 价值：高价值 = 业务关键，影响大
  • 依赖关系：是否可独立完成？
  • 复杂度：简单 = 组件少，边界清晰
  • 耦合度：低耦合 = 易于提取

Analysis Process

分析流程

Phase 1: Assess Current State

阶段1：评估当前状态

Analyze what's already been done:
  1. Check Component Inventory
    • Have components been identified and sized?
    • Is there a component inventory document?
    • Are oversized components identified?
  2. Check Common Component Analysis
    • Have common domain components been identified?
    • Are consolidation opportunities documented?
    • Has coupling impact been analyzed?
  3. Check Component Structure
    • Have components been flattened?
    • Are there orphaned classes?
    • Is component structure clean?
  4. Check Dependency Analysis
    • Have component dependencies been mapped?
    • Is coupling analysis complete?
    • Is feasibility assessed?
  5. Check Domain Identification
    • Have domains been identified?
    • Are components grouped into domains?
    • Are namespaces aligned with domains?
  6. Check Service Extraction
    • Have any services been extracted?
    • Are domain services created?
    • Is service-based architecture in place?
Output: Current state assessment showing what's done and what's remaining
分析已完成的工作：
  1. 检查组件清单
    • 是否已识别并确定组件规模？
    • 是否有组件清单文档？
    • 是否已识别超大组件？
  2. 检查通用组件分析
    • 是否已识别通用领域组件？
    • 是否已记录整合机会？
    • 是否已分析耦合影响？
  3. 检查组件结构
    • 是否已扁平化组件？
    • 是否存在孤立类？
    • 组件结构是否清晰？
  4. 检查依赖关系分析
    • 是否已映射组件依赖关系？
    • 耦合度分析是否完成？
    • 是否已评估可行性？
  5. 检查领域识别
    • 是否已识别领域？
    • 是否已将组件按领域分组？
    • 命名空间是否与领域对齐？
  6. 检查服务提取
    • 是否已提取任何服务？
    • 是否已创建领域服务？
    • 是否已实现基于服务的架构？
输出：当前状态评估，显示已完成和待完成的工作

Phase 2: Identify Patterns to Apply

阶段2：确定要应用的模式

Determine which decomposition patterns need to be applied:
  1. Review Pattern Prerequisites
    • Pattern 1: Always needed (foundation)
    • Pattern 2: Needed if common components exist
    • Pattern 3: Needed if components have hierarchy
    • Pattern 4: Always needed (feasibility check)
    • Pattern 5: Needed before service extraction
    • Pattern 6: Final step (service extraction)
  2. Check Pattern Completion
    • Which patterns are complete?
    • Which patterns are in progress?
    • Which patterns haven't started?
  3. Identify Missing Patterns
    • What patterns still need to be applied?
    • What's blocking pattern application?
    • What dependencies exist?
Output: List of patterns to apply with status
确定需要应用的分解模式：
  1. 查看模式先决条件
    • 模式1：始终需要（基础）
    • 模式2：若存在通用组件则需要
    • 模式3：若组件有层级则需要
    • 模式4：始终需要（可行性检查）
    • 模式5：服务提取前需要
    • 模式6：最终步骤（服务提取）
  2. 检查模式完成情况
    • 哪些模式已完成？
    • 哪些模式正在进行中？
    • 哪些模式尚未启动？
  3. 识别缺失的模式
    • 哪些模式仍需应用？
    • 哪些因素阻碍模式应用？
    • 存在哪些依赖关系？
输出：待应用模式列表及状态

Phase 3: Prioritize Work

阶段3：工作优先级排序

Prioritize decomposition patterns and work items:
  1. Assess Risk
    • Low Risk: Infrastructure components, standalone functionality
    • Medium Risk: Domain components with some dependencies
    • High Risk: Core business logic, high coupling
  2. Assess Value
    • High Value: Business-critical, high impact, frequent changes
    • Medium Value: Important but not critical
    • Low Value: Nice to have, low impact
  3. Assess Dependencies
    • Independent: Can be done without other work
    • Dependent: Requires other patterns/work first
    • Blocking: Blocks other work from proceeding
  4. Calculate Priority Score
    Priority = (Value × 3) - (Risk × 2) - (Dependencies × 1)

Higher score = Higher priority
Output: Prioritized list of patterns and work items
对分解模式和工作项排序优先级：
  1. 评估风险
    • 低风险：基础设施组件、独立功能
    • 中风险：有部分依赖的领域组件
    • 高风险：核心业务逻辑、高耦合组件
  2. 评估价值
    • 高价值：业务关键、影响大、频繁变更
    • 中价值：重要但非关键
    • 低价值：锦上添花、影响小
  3. 评估依赖关系
    • 独立：无需其他工作即可完成
    • 依赖：需先完成其他模式/工作
    • 阻塞：阻碍其他工作推进
  4. 计算优先级得分
    优先级 = (价值 × 3) - (风险 × 2) - (依赖关系 × 1)

得分越高 = 优先级越高
输出：按优先级排序的模式和工作项列表

Phase 4: Create Phased Roadmap

阶段4：创建分阶段路线图

Build a phased roadmap with milestones:
  1. Define Phases
    • Phase 1: Analysis & Preparation
    • Phase 2: Domain Organization
    • Phase 3: Service Extraction
    • Phase 4: Optimization & Refinement
  2. Assign Patterns to Phases
    • Which patterns belong in which phase?
    • What's the sequence within each phase?
    • What are the phase dependencies?
  3. Set Milestones
    • What marks completion of each phase?
    • What are the success criteria?
    • What deliverables are expected?
  4. Estimate Timeline
    • How long will each phase take?
    • What are the dependencies?
    • What's the critical path?
Output: Phased roadmap with timeline and milestones
构建包含里程碑的分阶段路线图：
  1. 定义阶段
    • 阶段1：分析与准备
    • 阶段2：领域组织
    • 阶段3：服务提取
    • 阶段4：优化与完善
  2. 为阶段分配模式
    • 哪些模式属于哪个阶段？
    • 每个阶段内的顺序是什么？
    • 阶段之间有哪些依赖关系？
  3. 设置里程碑
    • 每个阶段的完成标志是什么？
    • 成功标准是什么？
    • 预期交付物有哪些？
  4. 估算时间线
    • 每个阶段需要多长时间？
    • 存在哪些依赖关系？
    • 关键路径是什么？
输出：包含时间线和里程碑的分阶段路线图

Phase 5: Generate Architecture Stories

阶段5：生成架构需求故事

Create architecture stories for tracking work:
  1. Create Story Template
    As an architect, I need to [apply pattern/refactor component]
to support [architectural characteristic/business need]
so that [benefit/outcome]
  2. Break Down Work
    • One story per pattern application
    • One story per major refactoring
    • One story per domain grouping
  3. Add Acceptance Criteria
    • What defines "done"?
    • What metrics validate success?
    • What tests verify completion?
  4. Estimate Effort
    • Story points or time estimates
    • Complexity assessment
    • Risk factors
Output: List of architecture stories with estimates
创建用于跟踪工作的架构需求故事：
  1. 创建故事模板
    作为架构师，我需要[应用模式/重构组件]
以支持[架构特性/业务需求]
从而实现[收益/成果]
  2. 拆分工作
    • 每个模式应用对应一个故事
    • 每个重大重构对应一个故事
    • 每个领域分组对应一个故事
  3. 添加验收标准
    • 如何定义“完成”？
    • 哪些指标可验证成功？
    • 哪些测试可验证完成情况？
  4. 评估工作量
    • 故事点或时间估算
    • 复杂度评估
    • 风险因素
输出：带估算的架构需求故事列表

Phase 6: Track Progress

阶段6：跟踪进度

Monitor progress through decomposition:
  1. Track Pattern Completion
    • Which patterns are complete?
    • Which are in progress?
    • Which are blocked?
  2. Track Story Completion
    • Stories completed
    • Stories in progress
    • Stories not started
  3. Track Metrics
    • Components identified
    • Components refactored
    • Domains created
    • Services extracted
  4. Identify Blockers
    • What's blocking progress?
    • What dependencies are missing?
    • What risks have emerged?
Output: Progress dashboard and status report
监控分解进度：
  1. 跟踪模式完成情况
    • 哪些模式已完成？
    • 哪些正在进行中？
    • 哪些被阻塞？
  2. 跟踪需求故事完成情况
    • 已完成的故事
    • 进行中的故事
    • 未启动的故事
  3. 跟踪指标
    • 已识别的组件
    • 已重构的组件
    • 已创建的领域
    • 已提取的服务
  4. 识别阻塞因素
    • 哪些因素阻碍进度？
    • 缺少哪些依赖关系？
    • 出现了哪些风险？
输出：进度仪表板和状态报告

Output Format

输出格式

Decomposition Roadmap

分解路线图

markdown
undefined
markdown
undefined

Decomposition Roadmap

Decomposition Roadmap

Current State Assessment

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
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

Phased Roadmap

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

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
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)

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
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)

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
undefined
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
undefined

Prioritized Work Plan

Prioritized Work Plan

markdown
undefined
markdown
undefined

Prioritized Work Plan

Prioritized Work Plan

High Priority (Do First)

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
  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)

Medium Priority (Do Next)

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

Low Priority (Do Later)

Low Priority (Do Later)

  1. Service Extraction (Priority: 5/10)
    • Risk: High
    • Value: High (final goal)
    • Dependencies: Domain identification
    • Effort: 8 weeks
undefined
  1. Service Extraction (Priority: 5/10)
    • Risk: High
    • Value: High (final goal)
    • Dependencies: Domain identification
    • Effort: 8 weeks
undefined

Architecture Stories

Architecture Stories

markdown
undefined
markdown
undefined

Architecture Stories

Architecture Stories

Story 1: Flatten Ticket Components

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
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

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
undefined
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
undefined

Progress Dashboard

Progress Dashboard

markdown
undefined
markdown
undefined

Decomposition Progress Dashboard

Decomposition Progress Dashboard

Pattern Completion Status

Pattern Completion Status

PatternStatusProgressBlocker
Identify & Size Components✅ Complete100%None
Gather Common Components✅ Complete100%None
Flatten Components⚠️ In Progress60%None
Determine Dependencies❌ Not Started0%Waiting on flattening
Create Domains❌ Not Started0%Waiting on dependencies
Create Domain Services❌ Not Started0%Waiting on domains
PatternStatusProgressBlocker
Identify & Size Components✅ Complete100%None
Gather Common Components✅ Complete100%None
Flatten Components⚠️ In Progress60%None
Determine Dependencies❌ Not Started0%Waiting on flattening
Create Domains❌ Not Started0%Waiting on dependencies
Create Domain Services❌ Not Started0%Waiting on domains

Story Completion Status

Story Completion Status

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

Key Metrics

Key Metrics

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

Analysis Checklist

Analysis Checklist

Current State Assessment:
  • Reviewed component inventory
  • Checked common component analysis
  • Assessed component structure
  • Reviewed dependency analysis
  • Checked domain identification
  • Assessed service extraction status
Pattern Identification:
  • Identified which patterns are complete
  • Identified which patterns are in progress
  • Identified which patterns need to be applied
  • Checked pattern dependencies
Prioritization:
  • Assessed risk for each pattern
  • Assessed value for each pattern
  • Assessed dependencies
  • Calculated priority scores
Roadmap Creation:
  • Defined phases
  • Assigned patterns to phases
  • Set milestones
  • Estimated timeline
Story Generation:
  • Created architecture stories
  • Added acceptance criteria
  • Estimated effort
  • Prioritized stories
Progress Tracking:
  • Set up tracking mechanism
  • Defined metrics
  • Created dashboard
  • Identified blockers
Current State Assessment:
  • Reviewed component inventory
  • Checked common component analysis
  • Assessed component structure
  • Reviewed dependency analysis
  • Checked domain identification
  • Assessed service extraction status
Pattern Identification:
  • Identified which patterns are complete
  • Identified which patterns are in progress
  • Identified which patterns need to be applied
  • Checked pattern dependencies
Prioritization:
  • Assessed risk for each pattern
  • Assessed value for each pattern
  • Assessed dependencies
  • Calculated priority scores
Roadmap Creation:
  • Defined phases
  • Assigned patterns to phases
  • Set milestones
  • Estimated timeline
Story Generation:
  • Created architecture stories
  • Added acceptance criteria
  • Estimated effort
  • Prioritized stories
Progress Tracking:
  • Set up tracking mechanism
  • Defined metrics
  • Created dashboard
  • Identified blockers

Implementation Notes

Implementation Notes

Roadmap Templates

Roadmap Templates

Simple Roadmap (for small projects):
  • Phase 1: Analysis (2-4 weeks)
  • Phase 2: Refactoring (4-6 weeks)
  • Phase 3: Extraction (8-12 weeks)
Detailed Roadmap (for large projects):
  • Phase 1: Analysis & Preparation (4-8 weeks)
  • Phase 2: Domain Organization (4-6 weeks)
  • Phase 3: Service Extraction (12-16 weeks)
  • Phase 4: Optimization (4-8 weeks)
Simple Roadmap (for small projects):
  • Phase 1: Analysis (2-4 weeks)
  • Phase 2: Refactoring (4-6 weeks)
  • Phase 3: Extraction (8-12 weeks)
Detailed Roadmap (for large projects):
  • Phase 1: Analysis & Preparation (4-8 weeks)
  • Phase 2: Domain Organization (4-6 weeks)
  • Phase 3: Service Extraction (12-16 weeks)
  • Phase 4: Optimization (4-8 weeks)

Prioritization Matrix

Prioritization Matrix

Use a 2x2 matrix for prioritization:
High Value, Low Risk    | High Value, High Risk
(Do First)              | (Do Carefully)
────────────────────────┼──────────────────────
Low Value, Low Risk     | Low Value, High Risk
(Do Later)              | (Avoid/Defer)
Use a 2x2 matrix for prioritization:
High Value, Low Risk    | High Value, High Risk
(Do First)              | (Do Carefully)
────────────────────────┼──────────────────────
Low Value, Low Risk     | Low Value, High Risk
(Do Later)              | (Avoid/Defer)

Story Estimation

Story Estimation

Use story points or time estimates:
Story Points (Fibonacci):
  • 1: Trivial (few hours)
  • 2: Simple (1 day)
  • 3: Small (2-3 days)
  • 5: Medium (1 week)
  • 8: Large (2 weeks)
  • 13: Very Large (3+ weeks)
Time Estimates:
  • Small: 1-3 days
  • Medium: 1-2 weeks
  • Large: 2-4 weeks
  • Very Large: 1+ month
Use story points or time estimates:
Story Points (Fibonacci):
  • 1: Trivial (few hours)
  • 2: Simple (1 day)
  • 3: Small (2-3 days)
  • 5: Medium (1 week)
  • 8: Large (2 weeks)
  • 13: Very Large (3+ weeks)
Time Estimates:
  • Small: 1-3 days
  • Medium: 1-2 weeks
  • Large: 2-4 weeks
  • Very Large: 1+ month

Best Practices

Best Practices

Do's ✅

Do's ✅

  • Start with analysis patterns (Patterns 1-4)
  • Prioritize low-risk, high-value work
  • Create architecture stories for tracking
  • Set clear milestones and success criteria
  • Track progress regularly
  • Adjust roadmap based on learnings
  • Collaborate with stakeholders on priorities
  • Start with analysis patterns (Patterns 1-4)
  • Prioritize low-risk, high-value work
  • Create architecture stories for tracking
  • Set clear milestones and success criteria
  • Track progress regularly
  • Adjust roadmap based on learnings
  • Collaborate with stakeholders on priorities

Don'ts ❌

Don'ts ❌

  • Don't skip analysis patterns
  • Don't start service extraction too early
  • Don't ignore dependencies between patterns
  • Don't create unrealistic timelines
  • Don't skip progress tracking
  • Don't forget to validate with stakeholders
  • Don't proceed without feasibility assessment
  • Don't skip analysis patterns
  • Don't start service extraction too early
  • Don't ignore dependencies between patterns
  • Don't create unrealistic timelines
  • Don't skip progress tracking
  • Don't forget to validate with stakeholders
  • Don't proceed without feasibility assessment

Integration with Other Skills

Integration with Other Skills

This skill coordinates the use of other decomposition skills:
  1. Component Identification & Sizing → Foundation for planning
  2. Common Domain Component Detection → Identifies consolidation work
  3. Component Flattening → Prepares for domain grouping
  4. Component Dependency Analysis → Validates feasibility
  5. Domain Identification & Grouping → Enables service extraction
  6. Decomposition Planning & Roadmap (this skill) → Coordinates everything
This skill coordinates the use of other decomposition skills:
  1. Component Identification & Sizing → Foundation for planning
  2. Common Domain Component Detection → Identifies consolidation work
  3. Component Flattening → Prepares for domain grouping
  4. Component Dependency Analysis → Validates feasibility
  5. Domain Identification & Grouping → Enables service extraction
  6. Decomposition Planning & Roadmap (this skill) → Coordinates everything

Next Steps

Next Steps

After creating the roadmap:
  1. Review with Stakeholders - Get buy-in on plan
  2. Start Phase 1 - Begin with analysis patterns
  3. Track Progress - Monitor completion and blockers
  4. Adjust as Needed - Update roadmap based on learnings
  5. Celebrate Milestones - Recognize progress
After creating the roadmap:
  1. Review with Stakeholders - Get buy-in on plan
  2. Start Phase 1 - Begin with analysis patterns
  3. Track Progress - Monitor completion and blockers
  4. Adjust as Needed - Update roadmap based on learnings
  5. Celebrate Milestones - Recognize progress

Notes

Notes

  • Roadmaps should be living documents, updated regularly
  • Prioritization may change as you learn more
  • Dependencies between patterns must be respected
  • Feasibility assessment is critical before proceeding
  • Stakeholder collaboration is essential for success
  • Progress tracking helps identify issues early
  • Roadmaps should be living documents, updated regularly
  • Prioritization may change as you learn more
  • Dependencies between patterns must be respected
  • Feasibility assessment is critical before proceeding
  • Stakeholder collaboration is essential for success
  • Progress tracking helps identify issues early