Diseño Dirigido por el Dominio
Enfoque de diseño de software que centra el desarrollo en el dominio del negocio, usando un lenguaje ubicuo compartido entre desarrolladores y expertos de dominio.
¿Qué es?
Domain-Driven Design (DDD) es un enfoque de diseño de software que prioriza el modelado del dominio del negocio. La premisa: la complejidad real está en el dominio, no en la tecnología. DDD proporciona patrones para manejar esa complejidad.
Conceptos estratégicos
- Bounded Context: límite explícito donde un modelo de dominio es consistente
- Ubiquitous Language: vocabulario compartido entre devs y negocio
- Context Map: relaciones entre bounded contexts
- Subdomain: área del negocio (core, supporting, generic)
Conceptos tácticos
- Entity: objeto con identidad única
- Value Object: objeto definido por sus atributos (inmutable)
- Aggregate: cluster de entidades con una raíz
- Repository: abstracción de persistencia
- Domain Event: algo que ocurrió en el dominio
- Domain Service: lógica que no pertenece a una entidad
DDD y microservicios
Los bounded contexts de DDD mapean naturalmente a microservicios. Cada microservicio implementa un bounded context con su propio modelo y datos.
Cuándo aplicar DDD
| Situación | ¿DDD? | Alternativa |
|---|---|---|
| Dominio complejo con reglas de negocio ricas | Sí — DDD brilla aquí | — |
| CRUD simple sin lógica de negocio | No | Arquitectura en capas tradicional |
| Equipo sin acceso a expertos de dominio | Parcial — patrones tácticos sin el estratégico | — |
| Startup en exploración | No — demasiada ceremonia | Módulos simples, refactorizar después |
| Sistema legacy que se va a migrar | Sí — bounded contexts guían la descomposición | Strangler fig |
Errores comunes
- DDD sin expertos de dominio: el lenguaje ubicuo requiere conversaciones reales con el negocio, no suposiciones del equipo técnico
- Bounded contexts demasiado pequeños: un bounded context no es un microservicio por defecto — puede contener múltiples servicios
- Aggregate roots demasiado grandes: si un aggregate tiene más de 3-4 entidades, probablemente necesita descomponerse
- Ignorar el context map: las relaciones entre bounded contexts (customer-supplier, conformist, anticorruption layer) son tan importantes como los contexts mismos
¿Por qué importa?
DDD proporciona un lenguaje para alinear el código con el dominio del negocio. En sistemas complejos, los bounded contexts definen fronteras claras entre equipos y servicios, evitando el acoplamiento que convierte los monolitos en sistemas imposibles de modificar.
Referencias
- Domain-Driven Design — Eric Evans, 2003. El libro original.
- Implementing Domain-Driven Design — Vaughn Vernon, 2013.
- DomainDrivenDesign — Martin Fowler, 2020. Resumen del concepto de DDD.