The DDD Do-Over: Domain-Driven Design Lessons Learned
summary
Revisits two near-identical legal projects: the first is a forced “majestic monolith” with 195 controllers, 652 actions and 121 hard-coded roles that collapses everyone into a single Person model and duplicates scope across 50 county deployments, which causes ambiguous language, oversized tables and brittle repositories. The do-over focuses on bounded contexts (start with prosecution), uses CQRS as requests/handlers via a MediatR mediator, feature-by-feature folders, permission-based authorization, simple state-machine workflows and thin portals for police and defense — results: fewer controllers (~70), ~600 focused actions, 30 counties deployed and much happier users.
AI-written summary · about
chapters (13)
- 0:00Intro
- 2:21Part 1: The Majestic Monolith
- 12:18Bounded contexts are a thing
- 16:13Ubiquitous Language should be ubiquitous
- 17:25Core Domain needs consensus
- 19:30Ubiquitous language needs consensus
- 22:12Structural Patterns least important part of DDD
- 31:34Cohesiveness brings clarity and deeper insight
- 35:43Flexible in places, rigid in others
- 45:20Sometimes the model is a step up from the model
- 46:38First step to sanity: Collapse layers
- 52:43Don't blindly follow pattern advice
- 55:32Microservices and anti- corruption layers are your friend
related talks
48mDomain Driven Design: The Good Parts
39mLessons Learned from 10+ Years with Domain Driven Design
45mDon't Overdose on Domain-Driven Design
38m7 Years of DDD: Tackling Complexity
45mUsing DDD To Decompose Your Monolith
57mCombatting the Near Enemies of DDD -
51mDomain - Driven Transformation
44mStrategic Domain-Driven Design for dummies