Software Architecture
Explica cómo integrar bounded contexts mediante contratos, traducciones, eventos y context maps sin compartir modelos internos ni ownership de datos.
Bounded contexts necesitan colaborar sin compartir internals ni imponer un modelo universal. La integración correcta depende de qué información necesita el consumidor, cuánto puede esperar y qué consistencia exige el negocio.
Cada contexto posee su lenguaje y modelo. Integrar no significa fusionarlos, sino establecer contratos y traducciones explícitas.
contexto proveedor
→ contrato de integración
→ traducción
→ modelo local del consumidorLa forma de colaboración —síncrona, asíncrona o mediante datos replicados— cambia latencia, disponibilidad, consistencia y operación.
Si Pedidos lee directamente tablas de Inventario:
Si ambos comparten una librería de entidades:
La integración debe permitir autonomía sin ocultar los costos de comunicación.
Orders → Inventory.reserve → resultado inmediatoConviene cuando el consumidor necesita una respuesta antes de continuar.
El contrato debe distinguir:
type ReservationResult =
| { type: "reserved"; reservationId: string }
| { type: "insufficient-stock" }
| { type: "unknown"; requestId: string };Un timeout no equivale a rechazo. Puede requerir consulta o reconciliación.
Orders publica OrderConfirmed
→ Notifications envía mensajes
→ Reporting actualiza proyecciónRepresenta un hecho ya ocurrido. Reduce acoplamiento temporal y permite fan-out.
El consumidor debe ser idempotente y tolerar retrasos.
Indica que algo cambió y obliga a consultar al proveedor.
{ "type": "ProductUpdated", "productId": "p-1" }Contrato pequeño, pero crea llamadas y dependencia de disponibilidad.
Incluye datos suficientes para actualizar una proyección local.
{
"type": "ProductPriceChanged",
"productId": "p-1",
"price": { "minorUnits": 150000, "currency": "COP" },
"version": 12
}Mejora autonomía de lectura, pero amplía exposición y compatibilidad.
Un contexto puede mantener una copia local derivada.
Catalog es fuente de verdad
→ publica cambios
→ Orders mantiene ProductSnapshotDebe definir:
La réplica no se convierte en autoridad.
Traduce lenguaje externo:
Payments:
requires_capture
Orders:
paymentAuthorizedLa ACL puede incluir adapters, mappers, facades y políticas. Es especialmente útil frente a legacy o proveedores con modelos ajenos.
Un contrato publicado mediante OpenAPI, AsyncAPI, Protobuf o JSON Schema ayuda a compartir forma, pero debe acompañarse de semántica, ejemplos, compatibilidad y errores.
Upstream y downstream negocian evolución.
El consumidor adopta el modelo del proveedor. Reduce traducción, aumenta dependencia.
Ambos coordinan estrechamente. Útil cuando el éxito es compartido, costoso si se vuelve permanente.
Los contextos evitan integración porque el beneficio no justifica el costo.
Pedidos necesita conocer el precio utilizado al confirmar.
Opciones:
La decisión depende de:
Una solución razonable es que Orders consulte o reciba el precio autorizado y lo guarde como snapshot del pedido. Cambios posteriores de Catálogo no alteran pedidos históricos.
Cambios seguros no son únicamente aditivos. Agregar un enum puede romper consumidores exhaustivos.
Prácticas:
Usa versión por entidad y descarta estados antiguos.
Guarda event ID o aplica operación idempotente.
Define fallback, estado pendiente o degradación. No uses retries ilimitados.
Duplica representación local si evita coordinación semántica. La duplicación de datos puede ser preferible al acoplamiento.
Crea proyección o composición; no permitas escritura cruzada.
Estilos arquitectónicos y criterios de elección compara estructuras posibles según los drivers y capacidades del equipo.