Core DomainSupportingGeneric
El espacio del problema. Un Domain se divide en subdominios según su valor estratégico para el negocio.
Core Domain: Lo que te diferencia (el algoritmo de recomendaciones de Netflix).
Supporting: Necesario pero no diferenciador (gestión de usuarios).
Generic: Resuelto por software existente (facturación, autenticación).
Solo en el Core Domain vale la pena aplicar DDD completo. Para Generic Subdomains, compra o usa open-source.
Límite explícitoModelo propioAutonomía
Límite explícito dentro del cual un modelo de dominio es válido y consistente. Cada Bounded Context tiene su propio modelo, su propia BD y su propio equipo.
Ejemplo: "Pedido" en el contexto de Ventas tiene precio, descuentos y cliente. El mismo "Pedido" en Logística tiene peso, dimensiones y ruta. Son modelos distintos, aunque el concepto parezca igual.
1 Bounded Context ≈ 1 microservicio (en muchos casos). Pero un BC puede ser un módulo dentro de un monolito modular.
Lenguaje comúnNegocio = CódigoGlosario vivo
Lenguaje compartido y preciso que usan tanto el equipo técnico como los expertos del negocio. El mismo término tiene el mismo significado en conversaciones, diagramas, código y tests.
Ejemplo: Si el negocio llama "Suscripción" a lo que el código llama UserPlan, hay una brecha. Con UL, la clase se llama Subscription exactamente como el negocio lo llama.
El Ubiquitous Language es local al Bounded Context. "Cliente" puede significar cosas distintas en Ventas y en Soporte — y eso está bien.
Cliente
Ventas Persona con historial de compras, descuentos acumulados, segmento de valor.
Logística Dirección de entrega, zona geográfica, preferencia de horario.
Facturación RUT, datos fiscales, método de pago, saldo pendiente.
Pedido
Líneas de producto, totales, cupones aplicados, estado comercial.
Bultos, peso total, ruta asignada, estado de envío.
Monto facturado, impuestos, número de documento tributario.
Producto
Nombre, descripción de venta, precio de lista, categoría comercial.
SKU, dimensiones, peso, unidad de almacenamiento.
Código tributario, tasa de IVA aplicable, exención fiscal.
Cuenta
Suscripción activa, plan contratado, fecha de renovación.
No existe en este contexto.
Cuenta corriente, límite de crédito, estado de deuda.
Un BC es una unidad autónoma que contiene todo lo necesario para que su modelo sea consistente e independiente.
🧱
Modelo de dominio propio
Entities, Value Objects, Aggregates con semántica del contexto
🗄
Persistencia aislada
Ningún otro contexto accede a su BD directamente
📡
API o contrato de integración
La única forma válida de comunicarse con el exterior
🗣
Ubiquitous Language propio
Los términos tienen significado específico y preciso dentro del límite
Cuando dos equipos comparten una BD, no hay Bounded Contexts reales. Es el anti-pattern más común en arquitecturas legacy.
No hay una fórmula exacta, pero estas técnicas te ayudan a trazar los límites con el equipo de negocio.
EVENT STORMING
Taller colaborativo con post-its. Se mapean eventos de dominio en una línea de tiempo hasta que emergen las fronteras naturales entre contextos.
AMBIGÜEDAD SEMÁNTICA
Cuando el mismo término necesita distintos atributos según quién habla, ya hay un límite de contexto. El cambio de significado marca la frontera.
AUTONOMÍA ORGANIZACIONAL
Conway's Law: el equipo que puede hacer deploy independiente suele corresponder a un BC. Los límites de equipo y los de contexto tienden a coincidir.
Customer / Supplier
Upstream / Downstream
El equipo Upstream (proveedor) expone una API. El Downstream (cliente) se adapta. Si el Upstream cambia, el Downstream puede verse afectado.
La relación más común. Un BC depende del contrato que otro publica (REST API, eventos).
Anti-Corruption Layer
Downstream protegido
El Downstream crea una capa de traducción que aísla su modelo del modelo del Upstream. Los cambios del proveedor no contaminan el dominio propio.
Integración con sistemas legacy o APIs externas (terceros, ERPs). Fundamental para proteger el Core Domain.
Shared Kernel
Acuerdo mutuo
Dos contextos comparten un subconjunto del modelo (una librería común). Cualquier cambio requiere coordinación y acuerdo de ambos equipos.
Cuando dos contextos comparten conceptos muy estables (IDs, tipos de evento base). Evitarlo si los equipos tienen ciclos de release distintos.
Conformist
Sumisión total
El Downstream adopta completamente el modelo del Upstream sin crear una capa de traducción. El poder está totalmente del lado del proveedor.
Cuando integras con un sistema externo que no puedes controlar y cuyo modelo es suficientemente simple para adoptarlo tal cual.
Open Host Service
Upstream abierto
El Upstream expone un protocolo bien documentado y estable (API pública, eventos estándar) para que múltiples Downstream lo consuman sin customización.
Plataformas con muchos consumidores. El equipo Upstream invierte en mantener un contrato estable y versionado.
Separate Ways
Sin integración
Dos contextos no tienen integración directa. Cada uno resuelve el problema a su manera, duplicando si es necesario.
Cuando el costo de integración supera el beneficio. Duplicación controlada es mejor que acoplamiento accidental.