Thomas Coopman at DDD Europe
summary
Claims that Domain-Driven Design is not a standalone solution and only pays off when core engineering and org practices are present; recommends verifying bounded contexts, CI/CD pipelines, automated tests, observability and clear team ownership before investing in DDD. Argues that poor infrastructure, slow feedback loops, missing contracts and siloed teams block DDD’s benefits; when those are fixed DDD yields clearer models and fewer integration defects, otherwise it mostly adds ceremony.
AI-written summary · about
related talks
29m20 Years of Domain-Driven Design: What I’ve Learned About DDD
58mDDD really matters!
30mHow to Successfully Introduce DDD in an Organization
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
48mPitching DDD to the management
49mDomain-Driven Design & Team Topologies For Product-led Organizations
41mDomain-Driven Design: Hidden Lessons from the Big Blue Book
42mDomain Driven Design - So Your Code Speaks Plain Language