Software Architecture
Domain-Driven Design estratégico
Explica DDD estratégico mediante lenguaje ubicuo, subdominios, bounded contexts, context maps y límites alineados con capacidades y equipos.
- Última actualización
- Actualizada
- Nivel
- Aplicación
Software Architecture
Explica DDD estratégico mediante lenguaje ubicuo, subdominios, bounded contexts, context maps y límites alineados con capacidades y equipos.
DDD estratégico ayuda a decidir dónde termina un modelo y comienza otro. Su objetivo no es crear entidades sofisticadas, sino alinear lenguaje, límites, inversión y equipos con las partes realmente importantes del negocio.
En dominios complejos, una palabra puede significar cosas distintas según el contexto. Intentar construir un modelo universal produce objetos enormes, reglas contradictorias y coordinación constante.
DDD estratégico separa el dominio en subdominios y bounded contexts.
dominio del negocio
→ subdominios según capacidad y valor
→ bounded contexts con lenguaje consistente
→ relaciones explícitas entre contextosEn DomiSys, Product puede significar:
Forzar una sola clase Product para todo genera campos y reglas que no pertenecen juntas. DDD permite modelos distintos y traducción entre ellos.
Capacidad que diferencia el producto y merece conocimiento, diseño e inversión propios. Para DomiSys podría ser la coordinación operativa de inventario, ventas y pedidos para pequeños negocios.
Necesaria para el core, pero no diferencial. Puede requerir desarrollo propio por reglas particulares: configuración de sucursales o conciliación interna.
Problema común con soluciones maduras: autenticación, correo, almacenamiento de archivos o pagos. Suele ser candidato a comprar o integrar.
La clasificación no es permanente. Un subdominio puede volverse core si la estrategia del producto cambia.
El equipo y expertos usan términos consistentes dentro de un contexto.
“reservar stock”
→ reduce disponibilidad temporalmente
→ crea una reserva con expiración
→ no equivale a vender ni descontar definitivamenteEl lenguaje debe aparecer en conversaciones, código, reglas, eventos y documentación. Si negocio y software usan definiciones distintas, el modelo todavía no representa el dominio.
Es el límite dentro del cual un modelo mantiene significado consistente.
Catálogo
Product = descripción comercial, precio, variantes
Inventario
StockItem = cantidad, lote, ubicación, reservasEl bounded context no obliga a desplegar un microservicio. Puede ser un módulo dentro de un monolito.
Cambios de significado y terminología indican posibles límites.
Reglas que necesitan consistencia inmediata deberían permanecer cerca.
Capacidades que evolucionan por razones distintas pueden separarse.
Áreas gestionadas por personas distintas suelen poseer modelos diferentes.
Necesidades de seguridad, carga o autonomía pueden reforzar límites, pero no deberían ser el único criterio.
Describe cómo colaboran los contextos.
Un contexto upstream provee capacidades y negocia necesidades con downstream.
El consumidor acepta el modelo del proveedor. Reduce traducción, pero aumenta dependencia.
El consumidor traduce el modelo externo y protege su lenguaje.
El proveedor ofrece un contrato estable y un lenguaje publicado para varios consumidores.
Dos contextos coordinan evolución estrechamente. Requiere comunicación intensa y no escala a muchas relaciones.
Posibles contextos iniciales:
Catalog
→ productos, precios, variantes
Inventory
→ stock, reservas, movimientos
Sales/POS
→ ventas, pagos en caja, comprobantes
Orders
→ pedido del cliente y ciclo de preparación
Purchasing
→ proveedores, órdenes de compra, recepciónSaleCompleted.Ningún contexto necesita compartir todas sus entidades.
bounded context
→ límite semántico y de modelo
microservicio
→ límite de despliegue y operaciónUn bounded context puede contener varios servicios o varios contextos pueden coexistir temporalmente en una aplicación. Separar procesos antes de comprender significado produce servicios por entidad y contratos inestables.
Los límites también deben considerar carga cognitiva. Un equipo necesita comprender y operar su ámbito. Un contexto enorme con diez dominios no ofrece ownership real; demasiados contextos pequeños crean coordinación.
Money puede compartirse como value object estable. Customer suele tener significados distintos. Comparte únicamente semántica realmente común.
Puede consumir eventos o proyecciones sin convertirse en propietario de datos operacionales.
Trátalo como contexto externo y utiliza ACL si su modelo no debe contaminar el nuevo.
Puede mantener varios bounded contexts como módulos dentro del mismo repositorio y despliegue.
shared-domain universal.Product puede necesitar varios modelos?DDD táctico: entidades, value objects y agregados modela reglas dentro de un bounded context ya comprendido.