nw-legacy-refactoring-dddlisted

# Legacy Refactoring with DDD Refactoring legacy systems using Domain-Driven Design as the strategic compass. DDD tells you WHERE and WHY to refactor; traditional techniques (progressive-refactoring, mikado-method) tell you HOW. Principle: "Start simple, grow big" -- incremental steps tested at each stage. ## Decision Framework: Before Refactoring Ask three questions before any DDD refactoring: 1. **Business value**: what business outcome does refactoring this area enable? 2. **Risk**: what breaks if we refactor vs. if we do not? 3. **Cost**: time, effort, disruption -- is it justified? ### When NOT to Refactor - System scheduled for replacement - Stable system with no new development - Cost exceeds benefit - Team lacks DDD experience with no learning budget - Domain is genuinely simple (CRUD-dominated) ### Cynefin-Refactoring Mapping | Cynefin Domain | Refactoring Approach | |---------------|---------------------| | Clear | Apply established patterns directly; standard refactoring catalogs | | Complicated | Analyze with experts, then apply patterns; multiple valid solutions | | Complex | Probe with safe-to-fail experiments; EventStorming to discover patterns | | Chaotic | Act first to stabilize, then refactor; emergency patches acceptable | | Confusion | Gather information before deciding; avoid premature refactoring | ## Migration Methodology (4 Phases) ### Phase 1: Understand and Stabilize 1. Run EventStorming to map current system (Big Picture) 2. Assess complexi