7 Years of DDD: Tackling Complexity
summary
Seven-year evolution of a marketing platform shows DDD enabling fast delivery with anemic monolith first (two devs ship core features quickly) but forcing multiple rewrites later: CRM and commissions are thrown away and rebuilt as event sourcing and CQRS systems after business logic outgrows active-record scripts; a microservices attempt around one aggregate becomes a chatty distributed monolith; practical rule set emerges: invest in ubiquitous language, start with larger bounded contexts, and pick one of transaction script, active record, domain model, event source based on money/analytics/audit needs and complexity.
AI-written summary · about
chapters (8)
- 0:00Intro
- 2:39THE FIRST BOUNDED CONTEXT
- 8:33BOUNDED CONTEXTS PROTECT THE LANGUAGE
- 13:11THE CRUNCHERS BOUNDED CONTEXT
- 15:32THE BONUSES BOUNDED CONTEXT
- 18:47THE MARKETING HUB BOUNDED CONTEXT
- 25:26DOMAIN TYPES
- 30:40IMPLEMENTATION STRATEGIES
related talks
39mLessons Learned from 10+ Years with Domain Driven Design
01h 01mThe DDD Do-Over: Domain-Driven Design Lessons Learned
37mStart with DDD when you have a monolith
50mMoving away from CRUD: DDD + CQRS
48mDomain Driven Design: The Good Parts
45mUsing DDD To Decompose Your Monolith
42mHigh-Speed DDD (revisited)
56mDDD in Microservices: Complexity versus Complexity