Entrevistamos a Oriol Saludes y Álvaro García
summary
Explains why to adopt Domain-Driven Design by naming concrete patterns that change code and team behavior: bounded contexts, ubiquitous language, aggregates and context maps drive API and data boundaries. Argues DDD reduces accidental complexity, prevents large shared models, and makes releases safer by isolating changes; shows how aligning domain concepts with code improves onboarding and maintenance, and describes when DDD costs outweigh benefits.
AI-written summary · about
related talks
38mWhat I talk about when I talk about Domain Driven design
11mWe talk with Javier Ferrer González and Rafa Gómez Casas (Codely.tv) about DDD
55mDomain-Driven Design: back to the roots
31mIs Domain-Driven Design Overrated?
49mHow to cook Domain Driven Design
59mDomain-Driven Design - Where Rubber Meets the Road
45mDon't Overdose on Domain-Driven Design
48mDomain-Driven Design tactically and practically