Domain-Driven Transformation
summary
Claims that legacy monoliths can be incrementally re‑architected into vertical bounded contexts using a concrete four‑step recipe: re‑discover the domain, model the target architecture, align current code with tools (static analysis, EventStorming and domain storytelling), then do the move by creating empty modules, copying logic, forwarding calls and strangling the monolith. A catalog of refactorings and sprint‑sized tactical steps supports the work; transformation is possible, measurable, and slow but practical.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 2:32Legacy warehouse metaphor
- 9:30Legacy systems and value
- 13:26Refactorings for legacy systems
- 15:00Transforming a monolith
- 17:53Discovering domain knowledge
- 21:27Target architecture
- 24:19Current architecture analysis
- 27:33Big Ball of Mud problem
- 34:05Target architecture with bounded contexts
- 35:51Transformation planning
- 38:03Extracting bounded context
- 43:04Conclusion
- 45:35Q&A
related talks
40mArchitecture Modernization with DDD
37mBuilt to last: A domain-driven approach to beautiful systems
40mFrom Domain Boundaries to Software Architecture
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
54mDomain-Driven Design and Team Topologies for Product-led Organizations
01h 05mGetting to DDD: Pragmatic or Principled?
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
56mAligning Bounded Contexts with Subdomains in Legacy Code
