Domain driven redesign
summary
A 40‑year‑old in‑house 4GL with ~100,000 forms and 30 million lines of code moves from a proprietary binary DB to a Git-friendly JSON layout by adding a driver that emulates the old low‑level API, then incrementally replaces record types with about a dozen readable DSLs. The team uses roundtrip equivalence tests across the entire corpus, implements DSL tooling in Rascal and ships a VS Code editing workflow, and succeeds without breaking production behavior.
AI-written summary · about
chapters (11)
- 0:00Introduction and project context
- 5:13Legacy system challenges
- 9:00Requirements analysis approach
- 15:01Key project requirements
- 17:07Migrating to JSON database
- 21:01Designing DSLs for the domain
- 25:14Language design lessons
- 28:20Testing and validation strategy
- 32:10VS Code extension vision
- 35:44DDD benefits and takeaways
- 36:48Q&A session
related talks
42mTo DDD or not to DDD? Domain modelling case study
48mDomain Driven Design: The Good Parts
38mDomain-Driven Transformation - how to improve the structure of legacy systems
47mDomain Driven Transformation—How to Bring Back Sustainable Architecture to
01h 01mThe DDD Do-Over: Domain-Driven Design Lessons Learned
39mLessons Learned from 10+ Years with Domain Driven Design
40mLegacy Evolution – The Innovation Opportunity!
51mDomain - Driven Transformation