1. Presentación del módulo: comunicar para que entiendan, no para archivar

Descripción

Al terminar esta lección vas a entender la verdad más difícil de tragar para un ingeniero que se enorgullece de su rigor técnico: una decisión de arquitectura que nadie entiende no existe. Puedes tener el diseño perfecto en la cabeza —los límites en el lugar correcto, los trade-offs bien pensados, cada servicio con su responsabilidad clara—, pero si no logras que el VP de producto, el equipo de orders y el dev que llega en seis meses lo entiendan, entonces la arquitectura que se construye no es la que tú pensaste: es la que ellos entendieron. Y lo que ellos entendieron depende por completo de cómo se los comunicaste. Por eso comunicar no es el adorno final del oficio, la diapositiva bonita que haces cuando el trabajo de verdad ya terminó. Es donde el trabajo de verdad ocurre o se pierde. Este módulo entero es aprender a comunicar una arquitectura para que la entiendan, no para archivarla —dos propósitos que se parecen y son opuestos—.

Esto importa porque casi toda la documentación de arquitectura del mundo está escrita para el propósito equivocado. Está escrita para el archivo: el documento de 500 páginas que se produjo porque "hay que documentar" y que nadie abrió jamás; el diagrama que muestra los 200 componentes del sistema en una sola lámina, técnicamente completo y humanamente ilegible; el wiki que describía el sistema con precisión en 2021 y hoy miente porque el código cambió y el dibujo se quedó. Todos esos artefactos existen, ocupan espacio, dan la sensación de que "el sistema está documentado" —y no comunican nada—. La habilidad que este módulo enseña es la contraria: producir poco, pero que ese poco entre en la cabeza de la persona correcta a la primera. El arquitecto que domina esto no es el que más escribe; es el que elige qué mostrar, a quién, y con cuánto detalle.

Conexión con el módulo: esta lección es el mapa, no el territorio. Aquí no dibujas todavía a fondo; entiendes por qué las seis lecciones que siguen van en el orden que van. Primero la herramienta central: la lección 2 presenta el C4 model de Simon Brown —los cuatro niveles de zoom (Context, Container, Component, Code)—. Luego los dos mapas que más vas a usar: la lección 3 dibuja el Context y el Container de Mercado, uno para el negocio y otro para los devs. Después, cuándo seguir bajando y cuándo parar: la lección 4 cubre Component y Code y por qué casi nunca dibujas Code a mano. Con las cuatro herramientas en la mano, la lección 5 enseña lo más importante: elegir el diagrama correcto para la audiencia. La lección 6 añade la otra pieza de comunicación, el ADR como el porqué que viaja en el tiempo. Y la lección 7 te vacuna contra los dos grandes fracasos: el documento de 500 páginas y el diagrama-espagueti. La lección 8, el proyecto, te pone a producir el paquete de comunicación de Mercado para dos audiencias con tus manos.

Google Maps: eliges el zoom según lo que buscas

Piénsalo con una herramienta que usas todas las semanas: Google Maps. Cuando quieres entender dónde está un país en el mundo, alejas el mapa hasta ver continentes: fronteras, océanos, la posición relativa. A ese zoom no aparecen las calles, y está bien —no las necesitas para ubicar el país—. Cuando quieres saber cómo llegar de un barrio a otro dentro de una ciudad, acercas: aparecen las avenidas principales, las estaciones de metro, los ríos. Y cuando ya estás caminando y buscas el número de la casa, acercas al máximo: aparecen los edificios uno por uno, las esquinas, la entrada exacta. Es el mismo mapa —la misma ciudad, el mismo mundo—, pero a cada zoom ves una cantidad de detalle distinta, elegida para responder una pregunta distinta.

Ahora fíjate en lo que nadie hace: nadie intenta navegar una ciudad con el mapa del mundo —a ese zoom ni siquiera ves las calles—, y nadie cruza el país con el mapa de una sola calle —a ese zoom no sabes ni hacia dónde queda la autopista—. Y lo más importante: nadie dibuja un mapa que muestre al mismo tiempo los continentes y los números de las casas. Sería ilegible: o ves el mundo, o ves la calle, pero no los dos en la misma lámina, porque el detalle de uno tapa la forma del otro. El zoom que eliges depende por completo de la pregunta que traes y de qué tan cerca necesitas mirar.

Eso es el C4 model, y es todo el módulo condensado en una analogía. Comunicar una arquitectura es exactamente elegir el zoom del mapa según quién mira y qué pregunta trae. El VP de producto trae la pregunta del mundo: "¿qué hace este sistema y con quién habla?" —quiere el mapa del país—. El dev nuevo trae la pregunta de la ciudad: "¿de qué piezas se compone esto y dónde vive cada una?" —quiere el mapa de las avenidas—. El dev que va a meter mano en el checkout trae la pregunta de la calle: "¿qué hay dentro de esta pieza en concreto?". Un solo mapa no sirve para los tres, igual que un solo zoom de Google Maps no sirve para ubicar un país y encontrar una casa. El error más común al comunicar arquitectura —el que vamos a medir en un momento— es darle a alguien el zoom equivocado: mostrarle al VP el mapa de la calle, o al dev que va a codear solo el mapa del mundo. En los dos casos la persona se queda sin poder hacer lo que vino a hacer.

El caso: Mercado, un sistema y dos audiencias

A lo largo de la guía acompañamos a Mercado, el marketplace del ecosistema, con sus cinco squads —catalog, orders, payments, shipping, platform—. En este módulo la pregunta no es cómo está organizado Mercado (eso fue el módulo 2, Conway): es cómo lo comunicas. Y comunicar bien empieza por notar que Mercado no tiene una audiencia, tiene varias, y cada una necesita un mapa distinto:

• El VP de producto entra a una reunión porque quiere lanzar la venta a vendedores externos. No le importa qué base de datos usas ni cómo se llama el servicio de notificaciones. Le importa: ¿qué hace Mercado hoy? ¿con quién habla —el gateway de pagos, la API del carrier de envíos—? ¿dónde encaja lo nuevo? Su pregunta es del mundo. Un diagrama con 30 cajas técnicas lo pierde en el primer minuto y sale de la reunión pensando "esto es muy complejo, confío en el equipo" —que es la forma educada de decir "no entendí nada"—.
• Un dev nuevo llegó el lunes y en dos semanas tiene que arreglar un bug en el flujo de pedidos. No le sirve el mapa del mundo —"Mercado vende cosas" no le dice dónde tocar—. Necesita el mapa de la ciudad: ¿cuáles son las piezas desplegables? ¿la web app, la API, la base de datos, el índice de búsqueda? ¿cuál habla con cuál? Con eso ya sabe por dónde empezar a leer código. Si le das solo el mapa del mundo, pasa su primera semana perdido, preguntándole a todos dónde está cada cosa.

Mismo sistema. Dos mapas. Y elegir mal el mapa —darle al VP el del dev, o al dev el del VP— es la forma más común y más silenciosa de fracasar al comunicar: silenciosa porque nadie te dice "elegiste el zoom equivocado"; simplemente la reunión no avanza, o el dev tarda el triple en arrancar, y nadie sabe por qué. Antes de dibujar nada a fondo, veamos ese fracaso medido.

Ejemplo trabajado: el mismo sistema, cuatro mapas —y el error de dar el equivocado

El C4 le pone nombre a los cuatro zooms de Mercado. Cada nivel responde una pregunta para una audiencia, y cada nivel carga una cantidad distinta de detalle —de las 5 cajas del Context a las 40 del Code—. El siguiente código no analiza nada técnico del sistema: solo muestra los cuatro mapas de Mercado y luego reproduce el error más común, darle al VP el mapa del dev, para medir cuánto detalle de más recibe.

# El mismo sistema (Mercado), distintos mapas segun quien mira.
# C4: cada nivel de zoom tiene una audiencia y una cantidad de detalle.

c4_levels = {
    "Context":   {"zoom": 1, "elements": 5,  "audience": "VP, negocio, clientes"},
    "Container": {"zoom": 2, "elements": 9,  "audience": "arquitectos, devs, ops"},
    "Component": {"zoom": 3, "elements": 12, "audience": "dev que trabaja en ESE container"},
    "Code":      {"zoom": 4, "elements": 40, "audience": "el dev que edita ESE codigo hoy"},
}

print("Mercado es UN sistema. Pero admite cuatro mapas, uno por nivel de zoom:")
print()
print(f"{'Nivel':<11}{'Zoom':<6}{'Elementos':<11}Audiencia")
print("-" * 62)
for name, info in c4_levels.items():
    print(f"{name:<11}{info['zoom']:<6}{info['elements']:<11}{info['audience']}")
print()

# El error mas comun: darle al VP el mapa del dev.
vp_needs = "Context"
gave_vp = "Component"
overload = c4_levels[gave_vp]["elements"] - c4_levels[vp_needs]["elements"]
print(f"El VP pidio 'entender el sistema'. Le mostraron el diagrama {gave_vp}.")
print(f"El mapa correcto para el VP ({vp_needs}) tiene {c4_levels[vp_needs]['elements']} elementos.")
print(f"El que le mostraron tiene {c4_levels[gave_vp]['elements']}: {overload} cajas de mas que a el no le dicen nada.")
print("Resultado: el VP se pierde y concluye 'esto es muy complejo, confio en ti'.")
print("No comunicaste. Solo archivaste.")

Qué esperar. Al correrlo:

Mercado es UN sistema. Pero admite cuatro mapas, uno por nivel de zoom:

Nivel      Zoom  Elementos  Audiencia
--------------------------------------------------------------
Context    1     5          VP, negocio, clientes
Container  2     9          arquitectos, devs, ops
Component  3     12         dev que trabaja en ESE container
Code       4     40         el dev que edita ESE codigo hoy

El VP pidio 'entender el sistema'. Le mostraron el diagrama Component.
El mapa correcto para el VP (Context) tiene 5 elementos.
El que le mostraron tiene 12: 7 cajas de mas que a el no le dicen nada.
Resultado: el VP se pierde y concluye 'esto es muy complejo, confio en ti'.
No comunicaste. Solo archivaste.

Detente en las últimas dos líneas, porque son la tesis del módulo en una frase. El VP no recibió menos información de la que necesitaba: recibió más —siete cajas de más, cada una técnicamente cierta y humanamente inútil para él—. Y ese exceso no es neutro: es lo que lo pierde. El detalle que a un dev le sirve para trabajar, al VP lo entierra. Comunicar de más y comunicar de menos son el mismo error visto desde dos lados: en ambos, la persona no puede hacer lo que vino a hacer. La tabla de arriba es el C4 completo —cuatro niveles, cuatro audiencias, cuatro cantidades de detalle—, y todo el oficio de este módulo es aprender a elegir la fila correcta para la persona que tienes enfrente.

Ahora, ¿cómo se ve de verdad el mapa correcto para el VP —el Context, las 5 cajas—? Así de simple:

C4Context
    title Mercado - System Context (el mapa del VP)
    Person(customer, "Customer", "Compra productos en Mercado")
    Person(seller, "Seller", "Vende productos en Mercado")
    System(mercado, "Mercado", "Marketplace en linea")
    System_Ext(payments, "Payment Gateway", "Cobra las tarjetas")
    System_Ext(carrier, "Carrier API", "Genera guias y rastrea envios")

    Rel(customer, mercado, "Busca y compra")
    Rel(seller, mercado, "Publica y gestiona productos")
    Rel(mercado, payments, "Cobra pagos")
    Rel(mercado, carrier, "Solicita envios")

Cinco cajas y cuatro flechas. El VP mira esto y en treinta segundos entiende qué hace Mercado y con quién habla: los clientes compran, los vendedores publican, Mercado cobra con un gateway externo y envía con un carrier externo. Cero jerga técnica, cero base de datos, cero nombre de framework. No porque el VP sea tonto, sino porque a su pregunta —"¿dónde encaja abrir Mercado a vendedores externos?"— eso es lo único que hace falta ver. Ese es el mapa del mundo. En la lección 3 lo dibujamos a fondo, junto al mapa de la ciudad que necesita el dev.

El mapa de las seis lecciones

Las seis lecciones que siguen van en este orden por una razón: primero te doy la herramienta, luego te enseño a elegirla, y al final te vacuno contra los errores.

Lección	Qué te da	Por qué va aquí
2	El C4 model: los cuatro niveles de zoom	Es el vocabulario del módulo; sin él no puedes hablar de "elegir el zoom"
3	El Context y el Container de Mercado, dibujados	Son los dos mapas que vas a usar el 80% del tiempo
4	El Component y el Code, y cuándo parar	Para saber hasta dónde bajar y por qué casi nunca dibujas Code
5	Cómo elegir el mapa para la audiencia	Es el corazón: el mapa del VP no es el del dev
6	El ADR como comunicación	El diagrama muestra el qué; el ADR guarda el porqué que viaja en el tiempo
7	Cómo evitar el doc de 500 páginas y el espagueti	Es la vacuna contra los dos fracasos más comunes

El arco es: primero aprendes el lenguaje de los zooms (2), luego dibujas los dos mapas más útiles (3) y sabes hasta dónde seguir bajando (4). Con las herramientas en la mano, aprendes lo más difícil, que es elegir el mapa correcto para cada persona (5). Después añades la pieza que los diagramas no cubren —el porqué de las decisiones, con el ADR (6)— y por último te proteges de los dos modos de fallar (7). La lección 8 —el proyecto— junta todo produciendo el paquete de comunicación de Mercado para el VP y para un dev nuevo, para que confirmes que aprendiste a elegir el zoom y no solo a dibujar cajas.

Lo que este módulo NO toca

Conviene marcar la frontera desde ahora, porque hay temas vecinos que parecen de aquí y son de otra parte.

El rol del arquitecto en general fue el módulo 1. Ahí vimos qué hace de verdad —facilitador, no dictador; el que hace reversibles las decisiones caras y las comunica—. Este módulo se concentra en una sola dimensión de ese rol: cómo comunica. Cuando aquí digamos "el arquitecto le explica al VP", damos por sabido por qué comunicar es parte central del oficio (eso fue M1) y nos enfocamos en la técnica: qué mapa, a quién, con cuánto detalle.

La Ley de Conway fue el módulo 2. Ahí vimos que la organización moldea el sistema. Aquí vamos a diagramar sistemas, pero para comunicarlos a una audiencia, no para analizar la dinámica org↔arquitectura. Si en un diagrama de Mercado aparece que orders y payments comparten el checkout, aquí eso es un dato que comunicamos con claridad; por qué pasa y cómo se arregla fue Conway.

La mecánica del ADR es de la guía de architecture-decisions. El ADR tiene una estructura —Context, Decision, Consequences, Status— y una disciplina de cuándo escribirlo, cómo numerarlo, cuándo marcarlo como superseded. Todo eso se enseñó en la guía hermana architecture-decisions-and-tradeoffs. Aquí no re-explicamos su mecánica: lo usamos como herramienta de comunicación —el porqué de una decisión, empaquetado para que viaje en el tiempo hasta quien llegue después—. Cuando en la lección 6 generemos un ADR, la novedad no es su formato (ya lo conoces), es su papel: comunicar una decisión a un lector futuro que no estuvo en la sala.

Liderar sin autoridad es el módulo 4. Comunicar bien es necesario pero no suficiente para que una decisión se ejecute: además hay que influir, sostener las conversaciones que la mantienen viva, no volverse el cuello de botella. Todo eso —el liderazgo técnico sin autoridad formal— es el módulo que sigue. Aquí nos quedamos en la herramienta de comunicación; convertirla en ejecución real es M4.

Errores comunes

Creer que documentar es lo mismo que comunicar (de confusión de propósito). Qué pasa: alguien produce un documento de arquitectura enorme, exhaustivo, con todos los detalles, lo sube al wiki, y da por hecho que "el sistema está comunicado". Nadie lo lee. Por qué pasa: se confunde el artefacto (el documento existe) con el efecto (alguien entendió). Documentar es producir el archivo; comunicar es lograr que entre en una cabeza. Cómo detectarlo: pregunta si alguien usó el documento la semana pasada para tomar una decisión o entender algo; si la respuesta es "está ahí por si acaso", documentaste, no comunicaste. Cómo corregirlo: es todo el módulo —producir poco, dirigido a una audiencia concreta con una pregunta concreta, en el zoom que responde esa pregunta—.

Dar el mismo diagrama a todo el mundo (de audiencia única). Qué pasa: el arquitecto tiene un diagrama del sistema —normalmente el más detallado, porque es el que más trabajo le costó— y se lo muestra igual al VP, al dev nuevo y al equipo de ops. Uno se ahoga en detalle, otro no encuentra lo que busca, y solo por casualidad alguno estaba en el zoom correcto. Por qué pasa: hacer un diagrama cuesta, hacer cuatro cuesta más, y es tentador creer que "uno bueno sirve para todos". Cómo detectarlo: si usas el mismo dibujo en una junta de negocio y en un onboarding técnico, estás dándole a alguien el zoom equivocado. Cómo corregirlo: la lección 5 —emparejar audiencia con nivel; el mapa del VP no es el del dev, y eso no es opcional—.

Poner todo en una sola lámina (de miedo a omitir). Qué pasa: el diagrama muestra los sistemas externos, los containers, los componentes internos y hasta algunas clases, todo junto, con cien flechas cruzándose —el diagrama-espagueti—. Se ve impresionante y no comunica nada, porque mezcla niveles de abstracción que la cabeza no puede procesar a la vez. Por qué pasa: por miedo a omitir algo importante, se incluye todo; y porque un diagrama denso da una falsa sensación de rigor ("mira cuánto sé del sistema"). Cómo detectarlo: si tu diagrama tiene un tipo de caja que es "el sistema entero" y otra que es "una función", en la misma lámina, estás mezclando el mapa del mundo con el de la calle. Cómo corregirlo: la lección 7 —un diagrama, un nivel; la completitud vive en el conjunto de diagramas, no en cada uno—.

Ejercicios

Ejercicio 1 — ¿Qué zoom pide cada quien? Tres personas te piden "un diagrama de Mercado": (a) un inversionista que evalúa poner dinero en la empresa; (b) un ingeniero de otro equipo que va a integrar su sistema con la API de Mercado; (c) una desarrolladora que acaba de recibir el ticket de arreglar un bug específico en cómo se calcula el impuesto dentro del servicio de checkout. Sin dibujar nada, di qué nivel del C4 (Context, Container, Component o Code) le darías a cada uno y por qué.

Ver solución

(a) El inversionista → Context. Trae la pregunta del mundo: ¿qué hace la empresa, con quién se conecta, qué tan grande es el alcance? No le importa —ni entendería— cómo se llama la base de datos. El Context (5 cajas, cero jerga) le muestra que Mercado es un marketplace que conecta clientes y vendedores y depende de un gateway de pagos y un carrier de envíos. Ese es exactamente su nivel.

(b) El ingeniero que integra → Container. No va a meter mano en el código interno de Mercado, pero necesita saber con qué pieza habla su sistema: ¿hay una API? ¿qué expone? ¿cómo se despliega? El Container (nivel 2, el mapa de la ciudad) le muestra las piezas desplegables y sus fronteras, que es justo lo que necesita para integrar sin tener que entender las tripas de cada container. Darle el Context sería muy poco (no ve la API); darle el Component sería de más (no le importa cómo está partida la API por dentro).

(c) La desarrolladora con el ticket → Component (y quizás Code). Va a trabajar dentro de una pieza concreta —el servicio de checkout— en un detalle concreto —el cálculo del impuesto—. Necesita el mapa del barrio: qué componentes hay dentro del checkout, cuál calcula impuestos, de qué depende. Ese es el Component (nivel 3). El Code (nivel 4) casi nunca hace falta dibujarlo: para ver las clases exactas del cálculo, le sirve más abrir el código real en su IDE que un diagrama que se va a desactualizar. La regla: baja al Component para orientarse dentro de la pieza; para el detalle último, ve al código, no a un dibujo del código.

Ejercicio 2 — El diagrama que no comunicó. Un arquitecto presenta al comité ejecutivo (VPs de producto, finanzas y operaciones) el plan para escalar Mercado 10x. Proyecta un único diagrama con 34 cajas: los 5 containers, sus componentes internos, las colas de mensajes, las bases de datos, los caches y las integraciones externas, todo conectado con unas 50 flechas. Los ejecutivos asienten, hacen dos preguntas vagas y aprueban el presupuesto "confiando en el equipo". ¿Por qué esto es un fracaso de comunicación aunque el proyecto haya sido aprobado? ¿Qué debió mostrar?

Ver solución

Es un fracaso porque los ejecutivos no entendieron nada —aprobaron por confianza, no por comprensión—, y eso tiene un costo que aparece después: cuando el proyecto se complique y haya que pedir más presupuesto o explicar un retraso, el comité no tendrá el modelo mental para seguir la conversación, porque nunca lo tuvo. "Aprobaron" no es lo mismo que "entendieron"; el arquitecto consiguió el sí, pero no construyó la comprensión que necesitará en las siguientes diez reuniones. El "confiamos en el equipo" es la señal de alarma: es lo que dice la gente cuando el diagrama la perdió.

El problema técnico es el zoom equivocado y la mezcla de niveles: 34 cajas con componentes internos, colas y caches es el mapa de la ciudad-más-el-barrio-más-la-calle, todo encimado, para una audiencia que trae la pregunta del mundo. Debió mostrar un Context (nivel 1): Mercado, sus usuarios, sus dependencias externas, y encima de eso, marcado, dónde impacta el crecimiento 10x —quizás "aquí es donde el tráfico se multiplica y por eso hace falta invertir"—. Cinco o seis cajas, una idea clara, una decisión que el comité pueda de verdad evaluar. El detalle de los 34 componentes existe y es válido, pero es el mapa para el equipo técnico, no para el comité. Un diagrama, un nivel, una audiencia.

Ejercicio 3 — Comunicar no es solo dibujar. El equipo de Mercado decidió hace un año extraer el checkout a su propio servicio. El diagrama de Container ya muestra el nuevo Checkout Service como una caja aparte, correctamente. Hoy llega un dev nuevo, mira el diagrama, y pregunta: "¿por qué checkout está separado de orders si claramente están tan relacionados? Parece más simple juntarlos." El diagrama, por sí solo, no responde esa pregunta. ¿Qué le falta a la comunicación, y qué herramienta de este módulo lo resuelve?

Ver solución

Al diagrama le falta el porqué. Un diagrama comunica muy bien el qué —qué piezas hay, cómo se conectan, cómo se ve el sistema hoy—, pero es mudo sobre por qué el sistema es así y no de otra forma. El dev nuevo ve la foto correcta (checkout separado) pero no tiene el razonamiento detrás, así que su instinto —"parece más simple juntarlos"— es razonable y peligroso: sin conocer el motivo de la separación, podría proponer deshacerla y repetir el problema que la separación resolvió.

La herramienta que lo resuelve es el ADR como comunicación (lección 6). Un ADR titulado "Extraer checkout a su propio servicio" que registre el contexto (checkout vivía en orders pero payments lo tocaba en cada cambio; dos squads coordinando el flujo más crítico del negocio), la decisión (un equipo stream-aligned dueño del flujo completo) y las consecuencias (cambios más rápidos, a cambio de una llamada de red más). Ese ADR es el porqué que viaja en el tiempo: el dev nuevo lo lee, entiende que la separación no fue capricho sino la solución a un dolor real de coordinación, y ya no propone deshacerla. El diagrama muestra la foto; el ADR cuenta la historia de por qué la foto se ve así. Se necesitan los dos.

Resumen y siguiente paso

En esta lección conociste la tesis que sostiene el módulo: una decisión de arquitectura que nadie entiende no existe —comunicar no es el adorno del oficio, es donde la arquitectura ocurre o se pierde—. Con Google Maps viste el corazón del C4: eliges el zoom según la pregunta que traes, y nadie navega una ciudad con el mapa del mundo ni dibuja los continentes y los números de las casas en la misma lámina. Conociste a Mercado como un sistema con varias audiencias —el VP que trae la pregunta del mundo, el dev nuevo que trae la de la ciudad— y viste, ejecutado, que darle a alguien el zoom equivocado no es darle menos de lo que necesita: a veces es darle más, siete cajas de exceso que lo entierran. Y viste el primer mapa de Mercado, el Context de cinco cajas para el VP.

Antes de avanzar deberías poder: nombrar la diferencia entre documentar (producir el archivo) y comunicar (que alguien entienda); explicar la analogía del zoom y por qué un solo mapa no sirve para todas las audiencias; y reconocer que un diagrama comunica el qué pero no el porqué —para eso hace falta el ADR—.

Lo que sigue es aprender el vocabulario que hace posible todo lo demás. En la lección 2 vas a conocer el C4 model de Simon Brown a fondo: los cuatro niveles de zoom —Context, Container, Component, Code—, qué pregunta responde exactamente cada uno, para qué audiencia sirve, y por qué "una notación simple con cuatro niveles" le gana a la sopa de símbolos que casi nadie recuerda. Es el paso de "intuyo que hay que elegir el zoom" a "tengo cuatro zooms con nombre y sé qué hace cada uno".

Recursos

• Simon Brown — The C4 model (c4model.com) — la fuente de todo el módulo, escrita por el creador del modelo. Explica los cuatro niveles con ejemplos y la filosofía de "un mapa a distintos zooms". Gratis, conciso y con notación de referencia; el punto de partida obligado.
• Gregor Hohpe — The Software Architect Elevator — el libro que trata la comunicación del arquitecto como su habilidad central: subir al penthouse (negocio) y bajar a la sala de máquinas (código), traduciendo entre niveles. La idea de "comunicar por niveles según la audiencia" que sostiene este módulo entero.
• arc42 — plantilla de documentación de arquitectura (arc42.org) — una plantilla probada para documentar arquitecturas de forma que sobreviva; útil como esqueleto de "qué comunicar y en qué orden". La veremos a fondo en la guía de documentación; aquí, como referencia de estructura.
• Martin Fowler — Software Architecture Guide — el hub de Fowler sobre arquitectura, con ensayos sobre por qué la arquitectura importa y cómo comunicarla. Buen contrapunto conceptual al C4: el por qué comunicar, no solo el cómo.