El Diseño Dirigido por el Dominio (DDD, por sus siglas en inglés Domain-Driven Design) es un enfoque de desarrollo de software que sitúa el dominio del negocio en el centro de todas las decisiones de diseño. En lugar de empezar por la base de datos o por la tecnología, DDD propone empezar por comprender en profundidad el problema que estamos resolviendo y modelarlo en código de forma fiel. Esta lección sienta las bases conceptuales que necesitarás para abordar el resto del módulo: qué es realmente DDD, cómo se descompone un dominio, qué es un modelo de dominio y la diferencia crucial entre diseño estratégico y táctico. Comprender estos cimientos es esencial porque DDD no es una librería ni un framework, sino una forma de pensar que afecta a la arquitectura completa de tus aplicaciones.

1. ¿Qué es el Diseño Dirigido por el Dominio?
2. Dominio, subdominios y su clasificación (núcleo, soporte, genérico)
3. El modelo de dominio
4. Diseño estratégico frente a diseño táctico
5. Cuándo aplicar DDD (y cuándo no)

DDD fue formalizado por Eric Evans en su libro Domain-Driven Design: Tackling Complexity in the Heart of Software (2003). Su premisa central es sencilla de enunciar pero difícil de dominar: el software debe reflejar el dominio del negocio que automatiza.

El dominio es la esfera de conocimiento y actividad alrededor de la cual gira la aplicación. Para una aseguradora, el dominio incluye conceptos como pólizas, primas, siniestros, coberturas o asegurados. DDD sostiene que el mayor valor de una aplicación compleja no está en su tecnología, sino en lo bien que su código captura las reglas y el lenguaje de ese dominio.

Los tres pilares de DDD son:

• Colaboración estrecha con los expertos del dominio. Los desarrolladores no pueden modelar bien lo que no entienden. Se necesitan conversaciones constantes con quienes conocen el negocio.
• Un lenguaje compartido y preciso (el Lenguaje Ubicuo, que veremos en la lección 06-02) usado tanto al hablar como en el código.
• Un modelo de dominio explícito que evoluciona a medida que mejora la comprensión del problema.

DDD no es código primero ni base de datos primero: es modelo primero.

Un dominio grande rara vez es uniforme. Se descompone en subdominios, áreas más pequeñas y cohesionadas del negocio. Identificar y clasificar los subdominios es uno de los primeros ejercicios estratégicos de DDD, porque nos dice dónde invertir esfuerzo y dónde no.

Existen tres tipos de subdominios:

La clave práctica es esta: no todo merece el mismo esfuerzo. Aplicar un modelado rico de DDD a un subdominio genérico (por ejemplo, el envío de emails) es desperdiciar recursos. El esfuerzo de modelado debe concentrarse en el subdominio núcleo.

En este diagrama Mermaid de tipo graph TD (top-down, de arriba abajo):

• El nodo D representa el dominio completo de la aseguradora.
• Las flechas --> indican descomposición en subdominios.
• Se distinguen visualmente el subdominio núcleo (donde compite la empresa) de los de soporte y los genéricos.

El objetivo de este mapa es comunicativo: ayuda a la organización a ponerse de acuerdo sobre dónde está el verdadero valor.

Un modelo de dominio es una abstracción rigurosa y selectiva del conocimiento del dominio. No es un diagrama de base de datos ni un diagrama de clases UML cualquiera: es un sistema de conceptos, reglas y comportamientos que captura cómo funciona el negocio.

Características de un buen modelo de dominio:

• Es comportamiento, no solo datos. Un modelo anémico que solo tiene getters y setters no es DDD. El modelo debe contener las reglas del negocio.
• Usa el lenguaje del negocio. Las clases y métodos se llaman como los expertos del dominio nombran las cosas.
• Evoluciona. A medida que se aprende más del dominio, el modelo se refina.

Comparemos un modelo anémico con un modelo rico:

En el ejemplo anterior:

• La clase Poliza es un mero contenedor de datos.
• Cualquier código externo puede modificar prima o activa sin restricción alguna.
• Las reglas del negocio (¿cuándo se puede activar una póliza? ¿la prima puede ser negativa?) viven dispersas en servicios externos, no en el modelo. Esto se conoce como Anemic Domain Model y es un antipatrón en DDD.

Aquí el cambio es profundo:

• El constructor valida que la prima sea positiva: es imposible crear una Poliza inválida.
• El campo prima es final: no puede cambiarse tras la creación (inmutabilidad parcial).
• El método activar() encapsula la regla de negocio: solo una póliza en estado BORRADOR puede activarse. La regla vive dentro del modelo, no fuera.
• El estado solo cambia a través de métodos con nombres del negocio, no de setters genéricos.

Este es el corazón de DDD: el modelo protege sus propias reglas (invariantes).

DDD opera en dos niveles complementarios. Confundirlos es uno de los errores más habituales al empezar.

El diseño estratégico traza el mapa: decide los límites, los lenguajes y cómo se relacionan las distintas partes del sistema. El diseño táctico proporciona los patrones de implementación dentro de cada parte. Lo estratégico es más importante: un buen diseño táctico dentro de unos límites mal trazados sigue produciendo un mal sistema.

DDD tiene un coste: requiere tiempo, colaboración con expertos y una curva de aprendizaje. No es gratis y no siempre compensa.

Aplica DDD cuando:

• El dominio es complejo (muchas reglas de negocio, no solo CRUD).
• El proyecto es estratégico y de larga vida.
• Tienes acceso a expertos del dominio dispuestos a colaborar.

Evita o reduce DDD cuando:

• La aplicación es un CRUD simple sin apenas reglas.
• Es un prototipo desechable o una prueba de concepto.
• El subdominio es genérico y existe una solución comercial.

Regla práctica: la complejidad del enfoque debe ser proporcional a la complejidad del dominio.

• Confundir DDD con una arquitectura concreta. DDD no obliga a usar microservicios, ni hexagonal, ni event sourcing. Son enfoques que combinan bien, pero DDD es independiente de ellos.
• Empezar por los patrones tácticos. Muchos equipos saltan directamente a "hacer agregados y repositorios" sin haber hecho el trabajo estratégico. El resultado son límites mal puestos. Empieza siempre por lo estratégico.
• Crear modelos anémicos. Si tus clases de dominio solo tienen getters/setters, no estás haciendo DDD, estás haciendo procedimientos disfrazados de objetos.
• Aplicar DDD a todo. Reserva el esfuerzo para el subdominio núcleo. Para lo genérico, compra o reutiliza.
• Consejo: habla con los expertos del dominio en su lenguaje y escucha los sustantivos y verbos que usan: son las pistas de tu modelo.

Ejercicio 1. Para una plataforma de comercio electrónico, identifica al menos un subdominio de cada tipo (núcleo, soporte, genérico) y justifica la clasificación.

Ejercicio 2. Revisa la clase Poliza anémica del apartado 3. Identifica qué reglas de negocio quedan sin proteger y propón al menos dos métodos de comportamiento que deberían existir en un modelo rico.

Ejercicio 3. Indica si aplicarías DDD completo, DDD ligero o ningún DDD a cada caso, justificando la respuesta: (a) una herramienta interna para registrar las vacaciones de los empleados; (b) el motor de cálculo de primas de una aseguradora; (c) el módulo de envío de SMS de notificación.

Solución 1. Un ejemplo razonable:

• Núcleo: el motor de recomendaciones de productos, si es lo que diferencia a la plataforma de la competencia.
• Soporte: la gestión del catálogo de productos (necesaria, pero no diferenciadora frente a competidores).
• Genérico: la pasarela de pagos (problema resuelto por servicios como Stripe o Redsys; no se reinventa).

Solución 2. Reglas sin proteger: la prima puede ser nula o negativa; el estado activa puede cambiarse a cualquier valor sin control de transiciones válidas. Métodos de comportamiento propuestos: un constructor que valide la prima (como en el modelo rico), y métodos activar() y cancelar() que controlen las transiciones de estado permitidas en lugar de un setActiva(boolean).

Solución 3. (a) Ningún DDD o muy ligero: es un CRUD simple con pocas reglas. (b) DDD completo: es el subdominio núcleo, complejo y estratégico. (c) Ningún DDD: subdominio genérico; conviene usar un servicio o librería existente.

En esta lección hemos establecido los cimientos del Diseño Dirigido por el Dominio: hemos visto que DDD pone el dominio del negocio en el centro, que un dominio se descompone en subdominios núcleo, de soporte y genéricos —cada uno con su estrategia—, que el modelo de dominio debe ser rico en comportamiento y no un mero contenedor de datos, y que DDD opera en dos niveles, estratégico y táctico. También hemos aprendido a juzgar cuándo merece la pena aplicarlo.

A partir de aquí profundizaremos en cada nivel. En la siguiente lección, "Diseño Estratégico: Bounded Contexts y Lenguaje Ubicuo", abordaremos cómo trazar los límites del modelo y cómo construir el lenguaje compartido que mantiene la coherencia entre negocio y código.