Domain-Driven Design, o DDD, es una forma de disenar software alrededor del conocimiento del negocio. Su objetivo principal no es aplicar patrones, sino conseguir que el codigo hable el mismo idioma que el dominio que representa.
DDD aporta mas valor cuando el problema tiene reglas, excepciones, vocabulario propio y decisiones que no se entienden solo mirando tablas o pantallas.
- Introduccion a DDD
- Lenguaje ubicuo
- Entidades value objects y agregados
- Repositorios servicios y eventos
- Bounded contexts
- Integracion entre contextos
- Buenas practicas
- Modelado estrategico
- Eventos de dominio
- DDD tactico en backend
- Testing del dominio
- Proyecto final
En muchos proyectos el codigo acaba reflejando tecnologia, no negocio:
controllers/
services/
repositories/
models/Eso puede funcionar, pero no siempre explica conceptos como:
- Pedido confirmado.
- Factura vencida.
- Cliente con riesgo.
- Cupo agotado.
- Matricula cancelable.
- Producto reservable.
DDD intenta que esos conceptos vivan en el modelo y no solo en conversaciones, tickets o documentacion externa.
Ayuda a dividir el sistema:
- Subdominios.
- Bounded contexts.
- Context maps.
- Relaciones entre equipos y modelos.
Ayuda a disenar el modelo interno:
- Entidades.
- Value objects.
- Agregados.
- Repositorios.
- Servicios de dominio.
- Eventos de dominio.
- El negocio tiene reglas complejas.
- Hay muchas excepciones.
- Distintas areas usan palabras diferentes.
- El sistema va a crecer durante anos.
- Los errores de interpretacion son caros.
- CRUDs simples.
- Prototipos rapidos.
- Scripts internos.
- Aplicaciones donde la logica vive casi toda en otra plataforma.
DDD no empieza en el codigo. Empieza entendiendo el dominio con personas que lo conocen y llevando ese lenguaje al diseno del sistema.