Is Domain-Driven Design Overrated?
summary
Argues that DDD’s real, useful contributions are clear names for design problems and the ubiquitous language, plus the strategic idea of bounded context and tactical patterns, but warns against treating those patterns as dogma. Shows concrete alternatives: implementing core logic in the relational database, driving design from the UI, or modeling with algebraic/functional grammars, and highlights adapter styles like hexagonal architecture. Recommends using contexts as decision spheres and treating DDD patterns as starting points not mandatory rules.
AI-written summary · about
chapters (11)
- 0:00Intro
- 0:26What is DDD?
- 4:27Key aspect 1: Ubiquitous language
- 4:52Key aspect 2: Tactical patterns
- 6:13Key aspect 3: Strategic design
- 7:00Bounded contexts
- 9:29Conceptual extensibility
- 15:15Should design be domain-driven?
- 26:30Contexts revisited
- 27:38Is DDD overrated?
- 31:05Outro
related talks
45mDon't Overdose on Domain-Driven Design
35mTrivialization of DDD or Not?
38mWhat I talk about when I talk about Domain Driven design
41mDomain-Driven Design: Hidden Lessons from the Big Blue Book
55mDomain-Driven Design: back to the roots
59mDomain-Driven Design: A Recipe for the Pragmatist
02mEntrevistamos a Oriol Saludes y Álvaro García
59mDomain-Driven Design - Where Rubber Meets the Road