24. Mapas de contexto: relaciones entre áreas, equipos y modelos

24.1 Introducción

En el tema anterior vimos que un dominio grande puede dividirse en contextos delimitados. Pero esos contextos no quedan aislados: se relacionan, intercambian información, dependen unos de otros y muchas veces son mantenidos por equipos distintos. Para visualizar esas relaciones usamos un mapa de contexto.

Un mapa de contexto muestra cómo se conectan los modelos de distintas áreas del negocio. Ayuda a entender límites, dependencias, integraciones, traducciones de vocabulario y responsabilidades entre equipos.

24.2 Imagen conceptual de mapa de contexto

24.3 Qué es un mapa de contexto

Un mapa de contexto es una representación de los contextos delimitados y las relaciones entre ellos. No describe cada modelo interno con detalle, sino cómo esos modelos se conectan.

Por ejemplo, en una clínica podemos tener contextos de Turnos, Atención médica, Facturación, Notificaciones y Administración de pacientes. El mapa muestra cómo fluye la información entre ellos.

24.4 Para qué sirve

El mapa de contexto sirve para comprender el sistema completo sin mezclar todos los modelos. Permite ver qué áreas colaboran, qué modelos deben traducirse, qué dependencias existen y dónde pueden aparecer problemas de integración.

También ayuda a tomar decisiones organizacionales. Si dos equipos trabajan en contextos diferentes, el mapa permite acordar contratos, eventos, responsabilidades y límites de cambio.

24.5 Contextos y equipos

Un contexto delimitado puede coincidir con un equipo, pero no siempre ocurre. A veces un equipo mantiene varios contextos pequeños. Otras veces un contexto grande requiere más de un equipo. Lo importante es que las responsabilidades estén claras.

Cuando los límites del modelo y los límites del equipo están muy desalineados, suelen aparecer problemas de comunicación. El mapa de contexto ayuda a hacer visibles esas tensiones.

24.6 Relaciones entre contextos

Los contextos pueden relacionarse de muchas formas. Uno puede enviar eventos a otro, consultar información, publicar un contrato, consumir datos externos o traducir conceptos. Cada relación debe tener intención clara.

Por ejemplo, Turnos puede emitir el evento Turno atendido. Facturación puede consumir ese evento para generar una prestación facturable. Atención médica puede recibir información de agenda para asociar una consulta con un turno previo.

24.7 Traducción de modelos

Cuando dos contextos se comunican, no siempre comparten los mismos significados. Una información recibida debe traducirse al lenguaje del contexto receptor. Esto evita que un modelo invada al otro.

Por ejemplo, en Turnos existe Turno como reserva de una franja. En Facturación puede transformarse en Prestación facturable. No conviene que Facturación dependa internamente de todas las reglas de agenda, ni que Turnos conozca todos los detalles de facturación.

24.8 Contexto proveedor y contexto consumidor

En algunas relaciones, un contexto produce información y otro la consume. El proveedor define qué datos o eventos ofrece. El consumidor decide cómo interpretarlos dentro de su propio modelo.

Por ejemplo, el contexto de Turnos puede proveer eventos como Turno reservado, Turno cancelado o Turno atendido. El contexto de Notificaciones puede consumir esos eventos para enviar mensajes. El contexto de Facturación puede consumir Turno atendido para iniciar un proceso administrativo.

24.9 Contratos entre contextos

Cuando dos contextos se integran, necesitan contratos claros. Un contrato puede ser un evento, una API, un archivo, un mensaje o un acuerdo documental sobre datos compartidos. Lo importante es que ambas partes entiendan qué se intercambia y con qué significado.

Un contrato mal definido genera acoplamiento y ambigüedad. Si cambia el modelo interno de un contexto, no debería romper innecesariamente a todos los consumidores.

24.10 Relaciones sincrónicas y asincrónicas

Una relación sincrónica ocurre cuando un contexto necesita respuesta inmediata de otro. Una relación asincrónica ocurre cuando un contexto publica un evento o mensaje y otro lo procesa después.

En el análisis de dominio, no siempre hace falta decidir el mecanismo técnico exacto, pero sí conviene entender si un proceso depende de una respuesta inmediata o si puede resolverse como consecuencia posterior.

24.11 Ejemplo de mapa en sistema de turnos

Un mapa de contexto para una clínica podría incluir:

• Turnos: administra agendas, disponibilidad, reservas y cancelaciones.
• Atención médica: registra consultas, diagnósticos y evolución clínica.
• Facturación: gestiona prestaciones, importes, pagos y comprobantes.
• Notificaciones: envía recordatorios, confirmaciones y avisos.
• Administración de pacientes: gestiona datos personales y cobertura.

El mapa muestra cómo estos contextos intercambian eventos y datos sin mezclar sus modelos internos.

24.12 Tabla de relaciones

La siguiente tabla muestra relaciones posibles:

24.13 Qué no debe mostrar el mapa

Un mapa de contexto no debe convertirse en un diagrama de clases gigante ni en un diagrama de infraestructura. No necesita mostrar todas las entidades, atributos, tablas, servicios técnicos o endpoints.

Su nivel de detalle debe permitir entender relaciones entre modelos. Si el mapa se llena de detalles técnicos, pierde su propósito estratégico.

24.14 Preguntas para construir un mapa

Estas preguntas ayudan a construir un mapa de contexto:

• ¿Qué contextos delimitados existen?
• ¿Qué equipo o área conoce cada contexto?
• ¿Qué información necesita cada contexto de los demás?
• ¿Qué eventos o datos publica cada contexto?
• ¿Dónde se necesita traducción de vocabulario?
• ¿Qué dependencias son críticas para el negocio?
• ¿Qué relaciones son estables y cuáles cambian con frecuencia?

24.15 Errores frecuentes

Al trabajar con mapas de contexto, suelen aparecer estos errores:

• Intentar mostrar todos los detalles internos de cada contexto.
• Confundir mapa de contexto con arquitectura física.
• No indicar dirección de dependencia o flujo de información.
• No distinguir proveedor y consumidor de información.
• Permitir que un contexto use directamente el modelo interno de otro.
• No definir contratos claros entre contextos.
• No actualizar el mapa cuando cambian relaciones importantes.

24.16 Qué debes recordar de este tema

• Un mapa de contexto muestra contextos delimitados y relaciones entre ellos.
• Ayuda a entender dependencias entre áreas, equipos y modelos.
• No reemplaza los modelos internos de cada contexto.
• La comunicación entre contextos requiere contratos claros.
• Un contexto puede proveer información y otro consumirla con su propio significado.
• La traducción evita que un modelo invada a otro.
• El mapa debe mantenerse simple y enfocado en relaciones relevantes.

24.17 Conclusión

Los mapas de contexto permiten ver el dominio desde una perspectiva más amplia. Muestran cómo se relacionan contextos delimitados, qué información intercambian y dónde existen dependencias entre áreas o equipos. Son especialmente útiles cuando un único modelo ya no alcanza para explicar todo el negocio.

En el próximo tema estudiaremos modelos anémicos y modelos expresivos, analizando dónde conviene ubicar responsabilidades dentro del dominio.