DDD

Resumen

DDD, o domain-driven design, es un método de diseño que pone el dominio del negocio en el centro del software. En vez de organizar el sistema solo por capas técnicas o tablas de base de datos, DDD busca construir modelos que expresen reglas, lenguaje y límites del negocio.

Importa cuando el problema no es solo CRUD. Si las reglas cambian según el área, los términos significan cosas distintas para equipos distintos o las decisiones del negocio son complejas, DDD ayuda a que el código refleje esas diferencias explícitamente.

Alcance y supuestos

Este paquete cubre DDD como método conceptual: lenguaje ubicuo, modelo de dominio, bounded context, subdominios y señales prácticas para decidir cuándo usarlo. Se enfoca en la parte estratégica y de modelado, no en implementar todo el catálogo táctico.

No cubre en detalle agregados, entidades, value objects, repositorios, domain events, event storming, CQRS ni microservicios. Tampoco asume que DDD sea necesario para todo sistema: para un CRUD simple puede ser sobreingeniería.

Modelo mental

Piensa en un mapa de una ciudad hecho para distintos oficios. Un turista necesita calles y puntos de interés. Un electricista necesita transformadores y tendidos. Un bombero necesita hidrantes y rutas de acceso. Todos miran la misma ciudad, pero cada mapa resalta un modelo distinto según el trabajo que debe resolver.

DDD funciona igual. El dominio es la ciudad. El modelo no intenta copiar toda la realidad; selecciona conceptos útiles para resolver un problema. El lenguaje ubicuo es el vocabulario compartido que usan negocio y desarrollo dentro de ese mapa.

El límite es igual de importante que el mapa. Una palabra como "cliente" puede significar comprador en ventas, deudor en cobranza y usuario activo en soporte. DDD no fuerza una definición global falsa. Encierra cada significado en un bounded context para que el modelo sea coherente dentro de su frontera.

Uso práctico

Usa DDD cuando el valor del sistema depende de entender reglas de negocio y mantenerlas explícitas en el diseño:

• ✅ Un sistema de logística con reglas de despacho, rutas, capacidad y estados de entrega puede beneficiarse de modelos de dominio claros.
• ✅ Una fintech con conceptos distintos de cuenta, saldo, movimiento y liquidación necesita lenguaje preciso por contexto.
• ❌ Una pantalla administrativa que solo crea, lista y edita catálogos simples probablemente no necesita DDD completo.
• ❌ Usar nombres como Entity, Aggregate o Repository sin lenguaje de negocio no es DDD; es ceremonia técnica.

Ejemplo trabajado: separar el significado de “cliente” por contexto

Supón que una empresa tiene ventas y soporte. Ambos equipos hablan de "cliente", pero no significan exactamente lo mismo. Ventas mira oportunidades comerciales, etapa del pipeline y monto estimado. Soporte mira contratos activos, tickets abiertos y prioridad de atención.

Si el sistema intenta crear una sola clase Customer para todo, el modelo se contamina rápido:

type Customer = {
  id: string;
  pipelineStage?: "lead" | "qualified" | "won";
  estimatedDealValue?: number;
  activeContractId?: string;
  openTicketCount?: number;
  supportPriority?: "normal" | "urgent";
};

Ese tipo mezcla dos conversaciones. Algunos campos solo tienen sentido en ventas; otros solo en soporte. Cada cambio obliga a preguntar qué parte del sistema puede romperse porque el límite conceptual no está claro.

Con DDD, el primer paso no es elegir una arquitectura de carpetas. Es separar contextos y nombrar los modelos con el lenguaje de cada equipo:

type SalesAccount = {
  id: string;
  pipelineStage: "lead" | "qualified" | "won";
  estimatedDealValue: number;
};

type SupportCustomer = {
  id: string;
  activeContractId: string;
  openTicketCount: number;
  priority: "normal" | "urgent";
};

Ahora el código admite que ventas y soporte tienen modelos distintos. Pueden compartir un identificador externo, pero no comparten necesariamente las mismas reglas. El bounded context evita que un término común esconda significados incompatibles.

La decisión práctica es preguntar dónde vive cada regla. "Una oportunidad calificada debe tener monto estimado" pertenece a ventas. "Un cliente con contrato premium y ticket crítico tiene prioridad urgente" pertenece a soporte. DDD busca que esas reglas aparezcan en el modelo correcto, con palabras que negocio y desarrollo puedan revisar juntos.

Antes de aplicar DDD, revisa cuatro preguntas:

1. ¿El dominio tiene reglas que no caben bien en CRUD simple?
2. ¿Los expertos del negocio usan términos con significado preciso o ambiguo según contexto?
3. ¿Hay subdominios con ritmos de cambio y decisiones distintas?
4. ¿El costo de modelar explícitamente se justifica por la complejidad del negocio?

Si las respuestas son sí, DDD ayuda a ordenar conversaciones, límites y código. Si el problema es pequeño o estable, un diseño más simple puede entregar más valor con menos ceremonia.

Evidencia

• Domain Language, DDD Resources presenta Domain-Driven Design como un marco para tomar decisiones de diseño y un vocabulario para hablar del diseño del dominio.
• Martin Fowler, Domain Driven Design resume DDD como diseño basado en modelos del dominio y destaca el diseño estratégico con bounded contexts.
• Microsoft Learn, Use Domain Analysis to Model Microservices describe subdominios y bounded contexts como herramientas para analizar dominios y separar modelos coherentes.