Introducción teórica al Domain-Driven Design (DDD)
En el mundo del desarrollo de software, especialmente en sistemas complejos, uno de los mayores desafíos no es escribir código… sino modelar correctamente el dominio del negocio.
Domain-Driven Design (DDD), propuesto por Eric Evans, no es una arquitectura ni un framework. Es una forma de pensar y estructurar el software alrededor del conocimiento del dominio.
¿Qué es el «dominio»?
El dominio es simplemente el área de conocimiento o actividad a la que se dedica tu software.
Puede ser un banco, un sistema de salud, un ecommerce o una red social, en otras palabras, es el «Qué» sobre el que trabajamos.
Cuando me acerqué al concepto «DDD» me costó comprenderlo hasta que entendía que parte de una idea muy simple:
Para resolver problemas de negocio, el software debe reflejar con fidelidad el lenguaje, reglas y estructuras de ese dominio.
¿Por qué usar DDD?
DDD es útil cuando:
- Estás trabajando en dominios complejos que no se entienden con estructuras CRUD simples (alejados de los típicos dominios sencillos con los que todos nos hemos formado).
- Hay múltiples reglas de negocio que cambian con frecuencia, como por ejemplo en proyectos donde el cliente redefine especificaciones de manera iterativa.
- Necesitas que el equipo de negocio y desarrollo hablen el mismo lenguaje, esto es vital de cara a la integración de los equipos.
- Quieres separar bien las responsabilidades técnicas y del negocio.
Una experiencia que me hizo replantearlo todo
En un proyecto de gestión de tarjetas, teníamos todo el modelo basado en base de datos. Cada entidad era básicamente una tabla, y la lógica estaba repartida entre servicios, controladores y algunos utilitarios mal ubicados.
Todo funcionaba… hasta que la magnitud del proyecto requirió la entrada de más compañeros que se toparon con una tremenda diferencia de semántica entre el equipo de desarrollo y la documentación técnica o el equipo de diseño.
Cambios funcionales simples implicaban tocar 2 o 3 capas del sistema y muchas consultas. Fue ahí donde entendimos que lo que nos faltaba no era arquitectura técnica, sino modelo de dominio claro.
Incorporar DDD no fue algo repentino, pero con pasos pequeños —como ubicar las reglas dentro de objetos de dominio, y hablar con negocio usando sus términos— el impacto sobre el proyecto fue tremendo, y esto mejoró mucho la escalabilidad del mismo.
Los pilares de DDD
1. Ubiquitous Language (Lenguaje ubicuo)
Desarrolladores, analistas y expertos del negocio deben usar el mismo vocabulario para describir entidades, reglas, eventos y casos de uso.
Por ejemplo, si el negocio habla de “transferencia de saldo”, no deberías llamarlo MovimientoFinanciero en código. Llámalo TransferenciaSaldo. El código debe ser una extensión del lenguaje del dominio.
2. Modelado basado en el dominio
El modelo del dominio no es una base de datos ni una estructura técnica. Es una representación en código de cómo funciona el negocio.
Por eso, los objetos del dominio deben tener comportamientos relevantes, no ser simples contenedores de datos (no solo getters/setters).
3. Bounded Contexts (Contextos delimitados)
En sistemas grandes, el lenguaje y las reglas cambian según el contexto.
Un «cliente» en facturación no es lo mismo que un «cliente» en atención postventa.
Por eso, DDD propone dividir el sistema en contextos delimitados, cada uno con su propio modelo, lenguaje y reglas. Entre contextos se habla mediante integraciones claras, como eventos, APIs o mensajes.
¿Cuándo aplicar DDD?
DDD no es necesario en todos los proyectos. Si estás construyendo una app simple CRUD o un MVP rápido, probablemente no valga la pena.
Pero si estás construyendo un sistema central para tu negocio, con lógica crítica, procesos complejos y equipos múltiples (especialmente el tema de los equipos mútliples), aplicar DDD te da estructura, claridad y escalabilidad.
Opinión personal
Si estás en un proyecto donde los requisitos cambian constantemente y la lógica de negocio vive “en las cabezas” más que en el código, DDD puede ser el punto de inflexión.
No es fácil al principio, y muchas veces cuesta que negocio se involucre de verdad, pero cuando logras que desarrollo y negocio hablen el mismo idioma, la calidad del software cambia por completo.
Conclusión
Domain-Driven Design te ayuda a construir software que representa fielmente la realidad del negocio. Más que una técnica, es una forma de pensar: hablar el idioma del dominio, colaborar con expertos funcionales y organizar el software alrededor de lo que realmente importa.
Como pequeño apunte personal, un valor añadido que he encontrado para esta arquitectura es la facilidad de asimilación del dominio por parte de nuevos trabajadores en empresas con alta rotación.