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 complexity using Cynefin framework
3. Write characterization tests for critical paths (Feathers technique)
4. Identify bounded contexts in existing codebase via language divergence

Phase 2: Modularize the Monolith

1. Introduce module structure aligned with bounded contexts
2. Use mediator pattern for initial decoupling between modules
3. Apply fitness functions to measure progress (coupling, cohesion, dependency direction)
4. Refactor database schemas toward context alignment

Phase 3: Introduce Events and CQRS

1. Replace mediator with event-driven communication
2. Implement CQRS for contexts benefiting from read/write separation
3. Split databases per bounded context using expand/contract pattern
4. Use event-based data synchronization for cross-context data needs

Phase 4: Extract Services (if justified)

1. Evaluate microservices readiness (6 signals below)
2. Start with most independent bounded context
3. Use strangler fig pattern -- incrementally extract while legacy still runs
4. Apply appropriate saga pattern for distributed transactions

Microservices Readiness Signals

1. Clear domain boundaries already established
2. Scaling pressure on specific areas (not uniform)
3. Independent development needs across teams
4. Operational maturity (CI/CD, monitoring, automated testing in place)
5. Technical expertise in distributed systems
6. Business justification (not trend-following)

Strategic Refactoring Patterns

Strangler Fig

Build new DDD-modeled functionality alongside legacy. Route requests to new code as features complete. Legacy gradually shrinks until fully replaced. Changes are incremental, monitored, low risk of unexpected breakage.

Mikado integration: use Mikado exploration to discover dependencies between legacy components before extracting. Each Mikado leaf becomes an atomic refactoring step.

Bubble Context

Create a small bounded context (the "bubble") where DDD principles apply. The bubble communicates with legacy through an Anti-Corruption Layer. Progressively expand the bubble to encompass more legacy functionality.

Steps:

1. Identify the most valuable bounded context (core domain) for initial DDD investment
2. Create an ACL between the new context and legacy
3. Apply tactical DDD within the bubble (aggregates, value objects, domain events)
4. Gradually expand, moving more logic behind the ACL
5. Retire legacy components as new context absorbs their functionality

Evolve Context Map

Integration patterns change as refactoring progresses. Map current relationships, identify mismatches, propose new patterns. Typical evolution: Conformist -> Customer-Supplier with ACL -> Partnership.

Split Bounded Context

When a context grows too large or serves conflicting purposes:

1. Domain decomposition to break responsibilities into subdomains
2. Context mapping to plan the split and redefine integration patterns
3. Isolate related aggregates
4. Introduce domain events for communication
5. Gradually refactor dependent code

Validation: bounded context splits are driven by business evolution, not technical convenience. Validate with domain experts.

Merge Bounded Contexts

When separation causes more friction than value:

1. Identify redundancies (overlapping models, duplicate logic, tight coupling)
2. Establish unified ubiquitous language
3. Consolidate aggregates and deprecate redundant events
4. Revisit context map

Tactical Refactoring Patterns

These patterns apply tactical DDD concepts (aggregates, value objects, domain events, domain services, CQRS) to refactoring. For foundational definitions and design rules, load domain-driven-design from solution-architect/.

Pattern	What It Fixes	Key Step
Replace primitives with VOs	Primitive obsession	Create self-validating type, replace in aggregate, update mapping
Enrich anemic model	Logic in services, data in entities	Move business rules from service "if" statements into owning entity
Introduce domain events	Direct coupling between aggregates	Replace method calls with immutable past-tense events + handlers
Extract domain service	Cross-aggregate operations in application layer	Create stateless domain-typed service; guard against overuse
Introduce CQRS	Read/write contention on same model	Separate read DTOs from write aggregates; CQRS != event sourcing

Infrastructure Refactoring Patterns

Split Database by Bounded Context

Most challenging aspect of DDD refactoring. Use expand/contract pattern for safe migration.

1. Identify table ownership by bounded context
2. Expand: add new schema/tables aligned with target context
3. Migrate: copy data, set up synchronization
4. Contract: remove old schema after validation
5. Test integrity at each step

Event-Based Data Synchronization

When contexts need data owned by another context:

1. Owning context publishes integration events on state changes
2. Consuming context maintains read-only local copy, updated via event handlers
3. ACL translates between event format and local model
4. Accept eventual consistency (design for it, test for it)

Replace Mediator with Events

Prepare for microservice extraction. Mediator is a stepping stone, not a destination.

1. Identify all mediator interactions between modules
2. Define domain/integration events for each interaction
3. Implement event bus (in-process initially, message broker for distribution)
4. Remove mediator dependencies
5. Test behavioral equivalence (async vs. sync differences)

Extract Microservice

Only when module is stable, independently deployable, and business-justified.

1. Verify bounded context independence (no shared database, no synchronous coupling)
2. Extract module to independent service with own persistence
3. Define API contract and integration events
4. Deploy independently with monitoring
5. Apply saga pattern for any cross-service transactions

Fitness Functions for Progress

Measure refactoring progress with automated fitness functions in CI:

Metric	What It Measures	Tool Examples
Afferent coupling	Incoming dependencies to module	NDepend, SonarQube, jdepend
Efferent coupling	Outgoing dependencies from module	Same
Dependency direction	Dependencies flow correctly (inward)	ArchUnit, NetArchTest
Test coverage	Safety net for refactoring	Coverage tools
Cohesion	Relatedness of components within module	LCOM metrics

Define fitness function thresholds as acceptance criteria for refactoring stories.

Testing Strategy for Legacy Refactoring

Test Type	When	Purpose
Characterization tests	Before touching legacy code	Document current behavior as safety net
Contract tests	When splitting contexts	Verify interservice communication
Eventual consistency tests	After introducing events	Simulate network failures, verify convergence
Schema integrity tests	During database refactoring	Verify constraints and data integrity

Characterization tests (Feathers): run legacy code, observe output, write tests that assert current behavior -- even if behavior seems wrong. These tests protect against unintended changes during refactoring.

Integration with Existing Skills

• mikado-method: use Mikado exploration to discover dependencies before strangler fig extraction. Each Mikado leaf = one atomic DDD refactoring step
• progressive-refactoring: apply L1-L4 refactoring within each bounded context after DDD restructuring. DDD operates at architecture level; RPP operates at code level
• hexagonal-testing: each bounded context is a hexagon. Test domain logic through driving ports; mock driven ports for isolation