Domain Driven Design: The Good Parts
summary
Greenfield DDD work starts as a single monstrous bounded context and ends by splitting into focused services: the first system becomes a 195-controller, 652-action monolith with 121 security roles and deployments to ~50 counties; the redo narrows to a prosecution bounded context (70 controllers, ~600 actions, deployed to 20 counties), drops blanket repositories for CQS-style handlers with request/response objects, enforces permissions via controller attributes and permission checks, models workflows as dynamic state-machine transitions queued for workers, and uses PetaPoco/raw SQL fallback and hypermedia REST for gated integrations.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:34Part 1: The Majestic Monolith
- 12:41Bounded contexts are a thing
- 16:26Ubiquitous Language should be ubiquitous
- 19:38Core Domain needs consensus
- 22:22Ubiquitous language needs consensus
- 25:18Structural Patterns least important part of DDD
- 35:04Cohesiveness brings clarity and deeper insight
- 39:26Flexible in places, rigid in others
- 47:19Sometimes the model needs a model
- 51:58Don't blindly follow pattern advice
- 56:38Microservices and anti- corruption layers are your friend
related talks
01h 04mDomain Driven Design: The Good Parts
01h 11mAn introduction to DDD
50mDomain Driven Design in Cloud Native Environments
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
45mDomain Driven Modular Architecture
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
54mImplementing Domain Driven Design