Domain Driven Design: The Good Parts
summary
A greenfield monolith grows to 195 controllers, 652 actions and 120 roles while arguments over repositories and aggregates stall delivery. The second project slices by agency into bounded contexts, builds a prosecution system deployed to ~30 counties, models workflows as simple state machines with task-based permissions, removes generic repositories to call Hibernate and StructureMap directly, and prefers one-query-one-handler handlers plus an anti-corruption layer to integrate varied agency models.
AI-written summary · about
chapters (13)
- 0:00Intro
- 1:02Part 1: The Majestic Monolith
- 7:30Bounded contexts are a thing
- 9:19Ubiquitous Language should be ubiquitous
- 10:35Core Domain needs consensus
- 11:56Ubiquitous language needs consensus
- 14:53Structural Patterns least important part of DDD
- 17:12Part 2: The Do-over
- 21:32Cohesiveness brings clarity and deeper insight
- 23:36Flexible in places, rigid in others
- 30:10Sometimes the model needs a model
- 36:52Don't blindly follow pattern advice
- 43:37Microservices and anti- corruption layers are your friend
related talks
01h 01mThe DDD Do-Over: Domain-Driven Design Lessons Learned
59mDomain-Driven Design - Where Rubber Meets the Road
47mDomain Driven Transformation—How to Bring Back Sustainable Architecture to
39mLessons Learned from 10+ Years with Domain Driven Design
47mDomain-Driven Design: A Complete Example
55mDomain-Driven Design: back to the roots
45mDon't Overdose on Domain-Driven Design
01h 00mFrom Domain Driven Design DDD to Delivery