Domain Driven Design

Con este blog pretendo extraer las ideas y conceptos que han sido reveladores para mi y tambien compartir la gran experiencia que ha sido para mi leer este genial libro. El libro contiene 17 capitulos, los cuales estan separados en 4 secciones, en mi opinion ningun capitulo es prescindible ni poco importante, creo que es muy notorio la intencion de cada capitulo y el porqué forma parte del libro. Para estructurar mejor las ideas separaré las secciones tal cual lo hace el libro porque es bastante precisa.

Es importante mencionar que los terminos usados, no estoy muy seguro de la traduccion exacta al español por lo que lo cual en algunos casos los mantendre igual que el libro original. Por otro lado hay muchos conceptos que solo son mencionados; sin embargo son super importantes, no me extenderé en ellos sino me desviaria mucho de la intencion de este blog.

❤️ Poniendo el Modelo de Dominio a trabajar

La primera sección del libro sienta las bases de todo el enfoque de Domain-Driven Design. Aquí, Evans nos muestra que el corazón de cualquier software no es la tecnología, ni los frameworks, ni siquiera el código: es la habilidad para resolver problemas relacionados con el dominio para los usuarios, es decir es el modelo del dominio que es esa representación simplificada pero poderosa de la realidad que nos permite resolver problemas del mundo real. Una de las mejores analogias usadas en el libro, es que el modelo no es una copia fiel de la realidad, sino una versión de la misma, como una película 🎬 que captura solo lo relevante para el problema que queremos resolver. Pero tener un buen modelo no es suficiente; hay que usarlo en todo el proyecto. Esto significa unir diseño y código, mantener una conversación constante entre desarrolladores y expertos del negocio, y construir un Lenguaje Ubicuo que todos comprendan y usen. En otras palabras, no se trata de escribir código mecánicamente, sino de aprender continuamente sobre el negocio, refinar nuestras ideas 💡, experimentar, y moldear el software como una expresión viva del conocimiento que vamos descubriendo. El modelo debe estar tan arraigado en el código como en las conversaciones del equipo. Si todos entienden el modelo, lo usan, lo mejoran y lo viven, entonces sí estamos poniendo el modelo a trabajar.

🧱 Los bloques de contruccion de un modelo basado en el modelo

En esta sección, el libro baja del avión conceptual y aterriza en el terreno técnico. Evans presenta los bloques fundamentales con los que construimos modelos sólidos y mantenibles en el código. Aprendemos a diferenciar Entities, que tienen identidad propia y sobreviven al paso del tiempo (como un usuario o una orden), de los Value Objects, que no tienen identidad y solo describen algo (como una dirección o un rango de fechas). También entran en juego los Services, que representan operaciones importantes del dominio que no encajan en entidades ni objetos de valor, y deben estar nombrados con el Lenguaje Ubicuo. Luego, se introducen patrones para manejar el ciclo de vida de los objetos del dominio, donde aparecen los poderosos Aggregates (con sus raíces e invariantes), las Factories (que crean objetos complejos) y los Repositories (que permiten acceder a objetos persistidos como si vivieran en memoria).

Todo esto tiene un propósito mayor: evitar que la complejidad del software nos devore. Al usar estos patrones, reforzamos la integridad del modelo, lo mantenemos enfocado, aislado del caos exterior y más alineado con el negocio. El resultado es un sistema más comprensible, flexible y capaz de crecer sin romperse. Como dice Evans: diseñar software es una batalla constante contra la complejidad, y estos bloques son nuestras mejores armas. ⚔️

🔍 Refactorizando hacia una Visión Más Profunda

En esta sección, el libro se vuelve casi filosófico: ya no se trata solo de tener un modelo “correcto”, sino de perseguir un modelo más profundo, expresivo y alineado con el corazón del dominio. Evans nos recuerda que los modelos útiles no nacen perfectos: emergen iterativamente a través de conversaciones, descubrimientos y muchas refactorizaciones pequeñas que, eventualmente, pueden llevarnos a avances revolucionarios (los famosos breakthroughs). Refactorizar no es solo limpiar código: es refinar el pensamiento del equipo, es transformar el conocimiento implícito en conceptos explícitos y construir software que no solo funcione, sino que explique por qué funciona. Esta sección es un llamado a vivir en el dominio, escuchar el lenguaje que usamos y moldear el software como una historia que cobra sentido con cada cambio.

También se introduce el concepto de Supple Design (diseño maleable): un diseño que no se resiste al cambio, sino que lo invita. Para lograrlo, Evans propone prácticas como interfaces que revelan intención, funciones sin efectos secundarios, y estructuras con contornos conceptuales claros. Se habla de cómo los nombres, las restricciones explícitas, y hasta patrones como Strategy o Specification pueden hacer que el modelo sea más expresivo y elegante. Esta sección es una oda a la creatividad aplicada al código, y al valor de un diseño que no solo sea robusto, sino también un placer de usar y extender.

🌍 Diseño Estratégico

En esta última sección, Evans cambia el foco del “diseño en el código” al “diseño en el sistema completo”. Cuando una aplicación crece, no alcanza con tener un buen modelo: necesitás varios modelos bien organizados y equipos alineados para evitar el caos. Acá aparece uno de los conceptos más potentes de todo DDD: el Bounded Context. En lugar de forzar un único modelo para todo, se define un límite claro donde un modelo tiene sentido, y se acepta que otros contextos usarán modelos diferentes, incluso con términos distintos. Para orquestar todo esto, se usan herramientas como el Context Map, que muestra cómo los distintos contextos se relacionan entre sí (por ejemplo, con estrategias como Shared Kernel, Anticorruption Layer o Separate Ways).

También se profundiza el concepto de destilación del dominio, que ya venía apareciendo en capítulos anteriores, pero que acá se convierte en una estrategia formal para separar lo esencial del ruido en sistemas grandes y distribuidos. La clave está en identificar el Core Domain (donde vive el verdadero valor del negocio) y enfocarse en él, mientras que los subdominios genéricos o de soporte pueden simplificarse, tercerizarse o reutilizar soluciones existentes. Además, se exploran estructuras a gran escala, como capas de responsabilidad, metáforas o componentes enchufables, para organizar sistemas complejos sin perder la claridad. Finalmente, el libro cierra con una invitación a aplicar todo esto de manera estratégica y orgánica, reconociendo que los grandes cambios no ocurren por decreto, sino a través de principios compartidos, comunicación fluida y un diseño que evoluciona con el equipo y el dominio. Es una llamada a pensar como arquitectos de sistemas vivos, no como simples constructores de funciones.

🎯 Conclusión

Domain-Driven Design no es solo una técnica de modelado, es una forma de pensar el software con propósito. Nos recuerda que no construimos sistemas solo para que funcionen, sino para que resuelvan problemas reales con claridad y poder explicativo. Desde crear modelos que representen el negocio (no solo estructuras de datos), hasta diseñar código que hable el mismo idioma que los expertos del negocio. Aprendemos que las mejores soluciones no se imponen: se descubren, se refinan, se destilan. Que un buen nombre vale tanto como una buena implementación, y que las conversaciones con el negocio son tan importantes como los tests. Y quizás lo más importante: que los grandes sistemas no se construyen con recetas mágicas, sino con equipos que aprenden juntos, iteran sin miedo y diseñan con intención.