Ningún Bounded Context vive aislado. En un sistema real, los contextos necesitan colaborar: el de Suscripción consume datos del de Ventas, el de Facturación reacciona a las pólizas suscritas, etcétera. El Mapeo de Contextos (Context Mapping) es la disciplina de DDD que describe cómo se relacionan e integran los distintos Bounded Contexts y, sobre todo, qué tipo de relación de poder, dependencia y traducción existe entre ellos. Esta lección cierra el módulo conectando el diseño estratégico con la realidad organizativa: los patrones de mapeo no solo describen integraciones técnicas, sino también relaciones entre equipos. Comprenderlos te permitirá diseñar integraciones sanas y protegerte de modelos ajenos que podrían contaminar el tuyo.

1. ¿Qué es un Context Map y por qué importa?
2. Patrones de relación entre contextos
3. El Anti-Corruption Layer (ACL) en detalle
4. El Open Host Service y el Published Language
5. Dibujar un Context Map de ejemplo

Un Context Map es una representación —normalmente un diagrama— de todos los Bounded Contexts de un sistema y las relaciones entre ellos. No describe el detalle interno de cada contexto (eso es el diseño táctico), sino las fronteras y los puntos de contacto.

Su valor es doble:

• Técnico: muestra qué contexto depende de qué, por dónde fluyen los datos y dónde hacen falta traducciones.
• Organizativo: las relaciones entre contextos suelen reflejar relaciones entre equipos. Un contexto "río arriba" (upstream) impone su modelo; uno "río abajo" (downstream) debe adaptarse. Saber quién está arriba y quién abajo evita conflictos.

Dos conceptos transversales que aparecen en todos los patrones:

• Upstream (río arriba): el contexto que provee, del que otros dependen. Tiene más "poder": sus cambios afectan a los demás.
• Downstream (río abajo): el contexto que consume, que depende del de arriba y debe adaptarse a sus cambios.

DDD cataloga varios patrones de relación. Estos son los más importantes:

La diferencia clave entre Conformist y ACL es crucial:

• Conformist: "Me trago tu modelo tal cual, con sus defectos, porque me sale más barato que traducir."
• ACL: "No quiero tu modelo dentro de mi casa; pongo una capa que lo traduce al mío y me protege de tus cambios."

El Anti-Corruption Layer es probablemente el patrón más útil en sistemas que se integran con software legado o externo. Su misión es impedir que el modelo de otro contexto se filtre y corrompa el nuestro.

Imagina que tu contexto de Suscripción debe consultar un viejo sistema de scoring crediticio externo que devuelve datos crudos y con un modelo muy distinto al tuyo:

Este modelo externo es feo: códigos numéricos sin significado, flags con cadenas, nombres crípticos. Si lo dejamos entrar tal cual, contamina todo nuestro dominio.

Lo que conseguimos con el ACL:

• El sistema externo y su modelo feo quedan encapsulados detrás de ScoringCrediticioAcl. El resto de nuestro dominio nunca ve RespuestaScoringExterno.
• La traducción convierte cod_riesgo (un int sin significado) en un NivelRiesgo (un concepto claro de nuestro dominio) y el flag "S"/"N" en un boolean.
• Nuestro dominio recibe un PerfilCrediticio limpio, expresado en nuestro Lenguaje Ubicuo.
• Si el sistema externo cambia su formato, solo cambiamos el ACL; el resto del dominio queda intacto. Esta es la protección clave.

El ACL actúa como una membrana: hacia dentro habla nuestro idioma; hacia fuera, el del sistema externo.

Cuando un contexto upstream tiene muchos consumidores, no es razonable adaptarse a cada uno. En su lugar, publica un Open Host Service (OHS): una API estable y documentada que cualquiera puede consumir de forma estándar. Junto al OHS suele ir un Published Language: un formato de intercambio bien definido y versionado (por ejemplo, un esquema JSON o un contrato OpenAPI).

Por qué este contrato es un buen Published Language:

• Es explícito y versionado (PolizaSuscritaV1): los consumidores saben exactamente qué esperar, y una futura V2 no rompe a quienes usan la V1.
• Define los campos obligatorios (required) y sus tipos: es un acuerdo formal, no una estructura que cambia sin avisar.
• Está expresado en un formato neutral (esquema tipo JSON/OpenAPI), independiente de la tecnología interna del contexto que lo publica.

Con un OHS y un Published Language, el contexto de Pólizas puede tener decenas de consumidores (Facturación, Notificaciones, Reaseguro...) sin acoplarse a ninguno: todos hablan el lenguaje publicado.

Pongamos juntos los patrones en el Context Map de nuestra aseguradora:

Lectura del mapa y justificación de cada relación:

• Ventas → Suscripción (Customer-Supplier): Ventas es upstream y provee los leads; Suscripción es downstream y puede pedir a Ventas que incluya ciertos datos. Hay diálogo entre equipos.
• Suscripción → Scoring Externo (ACL): el sistema de scoring es externo y su modelo no nos gusta, así que lo aislamos tras una capa anticorrupción.
• Pólizas → Facturación / Notificaciones (Open Host Service): Pólizas tiene varios consumidores, así que publica una API/eventos estándar para todos.
• Pólizas ↔ Siniestros (Partnership): ambos evolucionan juntos y dependen mutuamente (un siniestro necesita la póliza vigente; la póliza refleja la siniestralidad), por lo que sus equipos coordinan los cambios de forma conjunta.

Este mapa permite a la organización ver de un vistazo dónde están las dependencias críticas, dónde hace falta protección (ACL) y dónde conviene estabilizar contratos (OHS).

• No tener Context Map. Sin él, las integraciones crecen de forma caótica y nadie sabe quién depende de quién. Dibújalo y manténlo actualizado.
• Ser Conformist por pereza cuando el modelo ajeno es malo. Adoptar tal cual un modelo defectuoso contamina el tuyo. Si el modelo externo es feo o inestable, invierte en un ACL.
• Compartir base de datos entre contextos. Es el peor "patrón": acopla los contextos por la BD y rompe sus fronteras. Intégralos por API o eventos, nunca por tablas compartidas.
• Shared Kernel demasiado grande. Cuanto más compartes, más coordinación necesitas. Mantén el núcleo compartido mínimo y muy estable, o no lo uses.
• No versionar el Published Language. Si cambias el contrato sin versión, rompes a todos los consumidores a la vez. Versiona siempre (V1, V2...).
• Consejo: las relaciones del Context Map son tanto técnicas como organizativas. Antes de elegir un patrón, pregúntate qué equipo tiene el poder y la disposición a colaborar; eso suele decidir entre Customer-Supplier, Conformist o ACL.

Ejercicio 1. Tu contexto debe integrarse con la API de un proveedor de pagos externo, grande y que no va a adaptar nada a ti, pero cuyo modelo es razonablemente limpio. ¿Qué patrón eliges y por qué? ¿Y si el modelo fuera caótico?

Ejercicio 2. Dos equipos comparten un módulo de "cálculo de impuestos" que ambos modifican constantemente y que provoca conflictos frecuentes. Identifica qué patrón están usando y propón una alternativa más sana.

Ejercicio 3. Para cada relación, indica cuál es el contexto upstream y cuál el downstream: (a) un contexto de Informes que lee datos del contexto de Ventas; (b) un Open Host Service de Catálogo consumido por Pedidos.

Solución 1. Si el modelo del proveedor es limpio y no negocia, el patrón natural es Conformist: adoptas su modelo tal cual porque es aceptable y traducirlo no compensaría. Si el modelo fuera caótico o inestable, lo correcto es un Anti-Corruption Layer que aísle tu dominio de ese modelo y te proteja de sus cambios.

Solución 2. Están usando un Shared Kernel (núcleo compartido) que es demasiado grande y volátil, de ahí los conflictos constantes. Alternativas más sanas: convertir el cálculo de impuestos en un contexto propio con un Open Host Service que ambos consuman, o asignar la propiedad a un equipo (upstream) y que el otro lo consuma como Customer-Supplier. Así se elimina la necesidad de modificar a la vez un código compartido.

Solución 3. (a) Ventas es upstream (provee los datos); Informes es downstream (depende de ellos). (b) Catálogo es upstream (publica el OHS); Pedidos es downstream (consume el servicio).

Con esta lección cerramos el módulo de Diseño Dirigido por el Dominio. Hemos visto que el Context Map revela cómo se relacionan los Bounded Contexts y que esas relaciones son a la vez técnicas y organizativas. Hemos estudiado los patrones clave —Partnership, Shared Kernel, Customer-Supplier, Conformist, ACL y Open Host Service— y la diferencia decisiva entre conformarse con un modelo ajeno (Conformist) y protegerse de él con una capa de traducción (ACL). Por último, hemos compuesto un Context Map completo que integra todos los patrones.

Con los cuatro pilares del módulo —conceptos fundamentales, diseño estratégico, diseño táctico y mapeo de contextos— dispones ya de un marco completo para abordar dominios complejos. El siguiente paso natural en el curso de Arquitectura de Aplicaciones es ver cómo estos contextos y modelos se materializan en estilos arquitectónicos concretos, como la arquitectura hexagonal y las arquitecturas dirigidas por eventos, que llevan a la práctica todo lo aprendido aquí.