Domain Driven Design: The Good Parts
summary
A greenfield DDD effort starts as a huge monolith with 195 controllers ~650 actions, 121 roles and an enormous repository of ad‑hoc queries that still ships to 50 counties, proving DDD can deliver but also bloat. A do‑over narrows scope into a bounded context, rebuilds around cases not people, uses a simple state‑machine workflow, feature folders and a mediator pattern, exposes targeted REST portals, reduces to ~70 controllers and successfully deploys to more counties.
AI-written summary · about
chapters (13)
- 0:00Intro
- 2:15Part 1: The Majestic Monolith
- 9:52Comprehensive system covering all aspects of juvenile process
- 15:32Bounded contexts
- 19:12Ubiquitous Language should be ubiquitous
- 22:43Core Domain needs consensus
- 26:37Ubiquitous language needs consensus
- 31:18Structural Patterns least important part of DDD Also: Layers are for cakes
- 34:20Part 2: The Do-over
- 43:20Cohesiveness brings clarity and deeper insight
- 46:46Flexible in places, rigid in others
- 56:18Sometimes the model is a step up from the model
- 56:42First step to sanity: Collapse layers
related talks
59mDomain Driven Design: The Good Parts
01h 11mAn introduction to DDD
45mDomain Driven Modular Architecture
50mDomain Driven Design in Cloud Native Environments
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
55mDomain Driven Design in practice - how to draw your domain boundaries IRL
54mImplementing Domain Driven Design
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD