Combatting the Near Enemies of DDD -
summary
A large criminal‑justice modernization uses CQRS and event sourcing but collapses multiple perspectives into one shared Case aggregate, causing merge conflicts, a physical rolling-pin merge process, and lost behavior. The team uncovers an abstract core/abstract case and reintroduces bounded contexts, context maps and explicit ceremonies so pre‑charge, prosecuted and court views coexist; implementation works incrementally (avoiding a big bang), reduces simultaneous‑update pain, and surfaces the tradeoffs between data consistency and user‑focused models. Slow down, model in code, distill.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:50Near Enemies
- 3:39The Project
- 5:25Constraints
- 6:53Discovery
- 9:51The Cases
- 11:45The People
- 14:20The Case
- 17:05The Domain Expert
- 23:40The Next Steps
- 25:08Design Forces
- 27:09Precharge Cases
- 28:57Abstract Cases
- 31:45Refactoring
- 35:23Icebergs Ice Cubes
- 41:06Context Maps
- 42:43Implementation
- 46:42CQRS
- 54:16Questions
related talks
01h 01mThe DDD Do-Over: Domain-Driven Design Lessons Learned
50mAll Models Are Wrong: Lessons from Real DDD Projects
38m7 Years of DDD: Tackling Complexity
50mMoving away from CRUD: DDD + CQRS
36mBeyond DDD 101 — a practice report on building multi–bounded‑context CQRS/ES applications
30mDomain-Driven Design + Command Query Responsibility Segregation + Event Sourcing
48mDomain Driven Design: The Good Parts
40mDDD, CQRS, Hexagonal, Onion,... Putting it together