Definición: Enfoque de diseno de software que centra la arquitectura en el dominio de negocio y su logica, usando contextos delimitados y lenguaje ubicuo para gestionar la complejidad.
— Fuente: NERVICO, Consultoría de Desarrollo de Producto
Que es Domain-Driven Design
Domain-Driven Design (DDD) es un enfoque de diseno de software que centra la arquitectura en torno al dominio de negocio y su logica. Propuesto por Eric Evans en 2003, DDD proporciona herramientas conceptuales como contextos delimitados (bounded contexts), agregados (aggregates) y lenguaje ubicuo (ubiquitous language) para construir sistemas que reflejen fielmente la complejidad del negocio al que sirven.
Como funciona
DDD comienza con una colaboracion estrecha entre desarrolladores y expertos del dominio para establecer un lenguaje ubicuo: un vocabulario compartido que se usa tanto en las conversaciones como en el codigo. El sistema se divide en contextos delimitados, cada uno con su propio modelo de datos y reglas de negocio. Dentro de cada contexto, los agregados agrupan entidades relacionadas y garantizan la consistencia. Los eventos de dominio comunican lo que ocurre entre contextos. Los repositorios abstraen el acceso a datos, y los servicios de dominio encapsulan logica que no pertenece a ninguna entidad concreta.
Por que importa
En sistemas complejos, el mayor desafio no es la tecnologia sino entender y modelar correctamente el negocio. DDD asegura que la estructura del codigo refleje la estructura del negocio, facilitando que los cambios en las reglas de negocio se traduzcan directamente en cambios de codigo predecibles. Tambien guia decisiones arquitectonicas criticas, como donde dividir microservicios o que equipos deben ser responsables de cada parte del sistema.
Ejemplo practico
Una empresa de logistica aplica DDD para modelar su sistema. Identifica tres contextos delimitados: gestion de envios, facturacion y seguimiento de flota. En el contexto de envios, “Paquete” es un agregado con sus propias reglas: peso maximo, dimensiones permitidas, restricciones de destino. En facturacion, el mismo paquete se representa de forma diferente, con datos fiscales y tarifas. Cada contexto tiene su propio modelo, y se comunican mediante eventos de dominio. Cuando el contexto de envios emite “PaqueteEntregado”, el contexto de facturacion genera la factura final automaticamente.
Terminos relacionados
- Clean Architecture - Patron estructural que complementa DDD separando capas de responsabilidad
- Microservicios - Arquitectura donde los bounded contexts de DDD guian la delimitacion de servicios
- CQRS - Patron que se aplica frecuentemente dentro de contextos DDD para optimizar lecturas y escrituras
Ultima actualizacion: Febrero 2026