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.
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.
Los bounded contexts de DDD mapean naturalmente a microservicios. Cada microservicio implementa un bounded context con su propio modelo y datos.
| 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 |
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.
Estilo arquitectónico que estructura una aplicación como colección de servicios pequeños, independientes y desplegables, cada uno con su propia lógica de negocio y datos.
Principios y prácticas para diseñar interfaces de programación claras, consistentes y evolucionables que faciliten la integración entre sistemas.
Patrón que separa las operaciones de lectura y escritura en modelos distintos, optimizando cada uno independientemente para rendimiento y escalabilidad.
Patrón arquitectónico que aísla la lógica de negocio del mundo exterior mediante puertos y adaptadores, facilitando testing y cambio de tecnologías.