Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
Instrucciones de origen · Vista previa de solo lectura
name
decomposition-planning-roadmap
description
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).
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
Step-by-Step Process
Assess Current State: Analyze codebase and identify what's been done
Identify Patterns: Determine which decomposition patterns to apply
Prioritize Work: Rank patterns by risk, value, and dependencies
Create Roadmap: Build phased plan with milestones
Generate Stories: Create architecture stories for tracking
Track Progress: Monitor progress through decomposition phases
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:
Identify and Size Components - Understand what you have
## 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
## 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
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
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
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
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
Integration with Other Skills
This skill coordinates the use of other decomposition skills:
Component Identification & Sizing → Foundation for planning
Common Domain Component Detection → Identifies consolidation work
Component Flattening → Prepares for domain grouping
