From Strategy to Flow: A Journey Using DDD to Achieve Flow
summary
Honest diagnosis identifies an unstable fragile monolith called classic and a planned NextG modular monolith, refactor‑in‑place using DDD bounded contexts, hexagonal ports‑and‑adapters, feature flags and in‑memory tests. A tiny proof domain session then Blue Pay lands in production, 11 developers swarm one feature, pull request cycle time drops and deployment frequency rises to about 10 deployments/week. Measurement uses DORA metrics; the refactor is incremental, pragmatic and working.
AI-written summary · about
chapters (12)
- 0:00Journey with DDD
- 1:27Origin of big ball of mud
- 5:21Architectural fragility
- 9:10Initial diagnosis and strategy
- 13:02Refining strategy with business benefits
- 21:32Cultural challenges of change
- 23:20Starting with session service
- 24:46Expanding to Blue Pay project
- 31:12Learning from mistakes
- 33:43Measuring success with DORA
- 36:55Did we achieve flow?
- 38:00Key takeaways
related talks
41mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
01h 04mDomain Driven Design: The Good Parts
01h 05mGetting to DDD: Pragmatic or Principled?
56mOptimizing for a fast flow of value with adaptive, socio-technical systems
26mTackling tech debt
40mArchitecture Modernization with DDD
45mLearning to Love DDD - a Tale of Two Products