Cuando comencé a estudiar Domain-Driven Design (DDD), pensaba que era una arquitectura como Clean Architecture o Hexagonal Architecture. Con el tiempo entendí que esa idea es uno de los errores más comunes.
DDD no define cómo organizar tu proyecto. Define cómo comprender y modelar el negocio.
Ahí está la diferencia.
El problema que DDD busca resolver
En muchos proyectos, el software termina reflejando la estructura de la base de datos en lugar del negocio.
Es común encontrar clases como:
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Balance { get; set; }
}
Y luego, toda la lógica termina distribuida en servicios, controladores o procedimientos almacenados.
El resultado es un modelo de dominio anémico: objetos que solo contienen datos y muy poco comportamiento.
DDD propone lo contrario.
El dominio debe ser el centro de la aplicación y contener las reglas del negocio.
Entonces… ¿qué es realmente DDD?
Según Eric Evans, creador de Domain-Driven Design, DDD es una forma de desarrollar software donde el diseño del sistema está guiado por el conocimiento del dominio del negocio.
En otras palabras:
Antes de pensar en la base de datos, los endpoints o la interfaz de usuario, debemos entender cómo funciona el negocio.
Eso implica trabajar de cerca con expertos del dominio para construir un modelo que represente correctamente la realidad.
Un ejemplo sencillo
Imaginemos un sistema bancario.
Una cuenta bancaria no debería permitir cualquier operación.
No tendría sentido que cualquier parte del código pudiera modificar el saldo directamente:
account.Balance -= 500;
En DDD, la propia entidad protege sus reglas:
public class BankAccount
{
public decimal Balance { get; private set; }
public void Withdraw(decimal amount)
{
if (amount <= 0)
throw new ArgumentException("El monto debe ser mayor que cero.");
if (Balance < amount)
throw new InvalidOperationException("Fondos insuficientes.");
Balance -= amount;
}
}
Ahora el objeto conoce las reglas del negocio y evita estados inválidos.
¿Dónde entra Clean Architecture?
Aquí suele surgir otra confusión.
DDD y Clean Architecture no compiten.
De hecho, funcionan muy bien juntos.
- DDD responde: ¿Cómo represento correctamente el negocio?
- Clean Architecture responde: ¿Cómo organizo mi aplicación para mantenerla desacoplada y fácil de mantener?
Es muy común encontrar aplicaciones que utilizan ambos enfoques al mismo tiempo.
¿Cuándo vale la pena usar DDD?
DDD brilla cuando el dominio es complejo.
Por ejemplo:
- Sistemas bancarios.
- Seguros.
- Salud.
- Logística.
- ERP.
- Comercio electrónico con reglas de negocio complejas.
Si estás desarrollando un CRUD sencillo para administrar categorías o usuarios, probablemente DDD sea más de lo que necesitas.
No todos los proyectos requieren el mismo nivel de complejidad.
Mi aprendizaje
Una de las lecciones más importantes que me ha dejado estudiar DDD es esta:
El verdadero reto no es escribir código. Es entender el negocio.
Si no comprendemos el problema que estamos resolviendo, ninguna arquitectura, patrón o framework podrá salvar el proyecto.
DDD nos recuerda que el software debe hablar el mismo idioma que el negocio.
Y ese cambio de perspectiva puede marcar una gran diferencia en la calidad del sistema.
¿Qué opinas?
¿Has utilizado DDD en algún proyecto? ¿Crees que aporta valor o que muchas veces se aplica donde no es necesario?