Mapa de contextos
El context map es el diagrama vivo que muestra todos los bounded contexts del sistema, sus relaciones y el flujo de dependencia upstream/downstream.
El context map es la representación visual y documentada del paisaje estratégico de un sistema: qué contextos existen, cómo se relacionan y en qué dirección fluye la dependencia. No es solo un diagrama decorativo; es una herramienta de toma de decisiones arquitectónicas y organizacionales.
La distinción upstream / downstream es el eje del mapa. El contexto upstream es quien provee: define el modelo o el contrato al que los demás se adaptan. El contexto downstream es quien consume y debe reaccionar a los cambios del upstream. Esta asimetría de poder tiene consecuencias directas en cómo se gobierna la relación entre equipos.
Dibujar el mapa requiere conversaciones con todos los equipos involucrados: cada equipo conoce sus dependencias y el tipo de relación que tiene con sus vecinos. El mapa emerge de esas conversaciones y debe revisarse periódicamente, especialmente cuando hay reorganizaciones de equipos o cambios de arquitectura.
El mapa revela acoplamiento oculto. Si al dibujarlo aparecen muchas flechas convergiendo en un mismo contexto, ese contexto probablemente tiene demasiadas responsabilidades o está actuando como un shared kernel implícito. Si hay ciclos (A depende de B que depende de A), hay un Big Ball of Mud en formación.
Un context map bien mantenido facilita la planificación de cambios: si se modifica el contrato de un upstream, el mapa muestra exactamente qué downstreams se ven afectados. También orienta las decisiones de despliegue: contextos sin dependencias pueden desplegarse de forma completamente autónoma.
# Context Map — ASCII diagram (generic system)
#
# Legend:
# [U] = Upstream [D] = Downstream
# ACL = Anti-Corruption Layer OHS = Open Host Service PL = Published Language
# SK = Shared Kernel CF = Conformist
┌─────────────────────┐
│ <context_core> [U]│ ◄── Core subdomain
│ (OHS + PL) │
└────────┬────────────┘
│ published API (v1/v2)
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│<context_a>[D]│ │<context_b>[D]│ │<context_c>[D]│
│ + ACL │ │ Conformist │ │ + ACL │
└──────────────┘ └──────────────┘ └──────────────┘
│ │
│ Partnership (bidirectional) │
▼ ▼
┌──────────────┐ ┌──────────────────┐
│<context_d>[U]│ │ <external_system>│
│ Shared Kernel with <context_a> │ (Big Ball of Mud│
└──────────────┘ │ — legacy) │
└──────────────────┘
# Rule: arrows show dependency direction (downstream → upstream)
# [D] contexts depend on [U]; [U] contexts must not depend on [D]
# Upstream/downstream table extracted from the map:
# <context_core> upstream to: <context_a>, <context_b>, <context_c>
# <context_a> downstream to: <context_core>; upstream to: <context_d>
# <context_b> downstream to: <context_core> (Conformist — no ACL)
# <context_c> downstream to: <context_core>, <external_system>Debugging lab
Detecta y corrige el error o la violación de diseño.
- 2.4.5.1
# The upstream context imports from a downstream context: # contexts/<context_core>/domain/model/core_aggregate.py from src.project.contexts.context_a.domain.model.a_entity import AEntity class CoreAggregate: def process(self, entity: AEntity): ...
- 2.4.5.2
# Two teams drew separate context maps that contradict each other: # Team A map: context_a is upstream, context_b is downstream # Team B map: context_b is upstream, context_a is downstream
- 2.4.5.3
# No context map exists; a developer notices a new cross-context dependency in a PR: # contexts/context_c imports from contexts/context_d without any documented pattern
- 2.4.5.4
# A context appears as both upstream and downstream to the same context (cycle): # context_a depends on context_b (context_b is upstream) # context_b also depends on context_a (context_a is upstream)
- 2.4.5.5
# The context map shows context_a has 8 downstream consumers. # Every time context_a changes its model, 8 teams need to update their code.