El modelo C4: contexto, contenedores, componentes y código

Mapas de tu código

El modelo C4 es un enfoque para diagramar la arquitectura de software creado por Simon Brown. Surgió de la formación en arquitectura de software que impartía desde aproximadamente 2006: según el sitio de C4, sus raíces se remontan a algún momento entre 2006 y 2009, los tipos de diagrama recibieron nombre a principios de 2010 y el nombre "C4" se usó por primera vez a principios de 2011. Brown había observado que los equipos a los que se pedía dibujar su arquitectura producían diagramas difíciles de entender: formas y colores sin explicar, cajas que podían ser cualquier cosa, desde una clase hasta un centro de datos, líneas sin etiqueta y varios niveles de detalle mezclados en una misma página. UML, que podría haber resuelto el problema, había caído en gran medida en desuso en el trabajo diario.

Su respuesta no fue una notación nueva, sino un pequeño conjunto de abstracciones y una jerarquía de diagramas construida sobre ellas, que él compara con los niveles de zoom de un mapa en línea. Empiezas con el país entero, te acercas a una ciudad, luego a un distrito y después a una calle. Cada nivel muestra una cantidad distinta de detalle con un propósito distinto, y siempre sabes en qué nivel estás mirando. C4 es deliberadamente independiente de la notación y de la herramienta: puedes dibujarlo en una pizarra, en una herramienta de dibujo o con una herramienta de modelado, siempre que sigas unas pocas reglas.

C4 se ha convertido en uno de los enfoques más usados para los diagramas de arquitectura porque es fácil de aprender, encaja de forma natural con el pensamiento de múltiples vistas de la Sección 4.2 y produce diagramas que pueden seguir tanto los desarrolladores como los lectores no técnicos. En términos de 42010, cada tipo de diagrama C4 es un punto de vista con su propio tipo de modelo; C4 simplemente mantiene pequeño el conjunto.

Las abstracciones: personas, sistemas de software, contenedores, componentes

C4 se basa en cuatro abstracciones, más el código. Una persona es un usuario humano del sistema: un cliente, un repartidor, un agente de soporte. Un sistema de software es el nivel más alto de abstracción, algo que aporta valor a sus usuarios y que normalmente pertenece a un equipo u organización, que lo construye; la plataforma de reparto de comida es uno, y también lo son el proveedor de pagos y el servicio de mapas de los que depende.

Un contenedor es algo que tiene que estar en ejecución para que el sistema funcione: en palabras de Brown, esencialmente un límite de ejecución alrededor de un código que se ejecuta o de unos datos que se almacenan. Son ejemplos una aplicación web del lado del servidor, una aplicación de una sola página que se ejecuta en un navegador, una app móvil, una aplicación de escritorio, una función serverless, un esquema de base de datos, un almacén de archivos o un topic de mensajes. Cada uno se puede desplegar o ejecutar por separado, y los contenedores se comunican entre sí a través de los límites de proceso, normalmente por una red.

Un componente es una agrupación de funcionalidad relacionada detrás de una interfaz bien definida, que vive dentro de un contenedor y se ejecuta en el mismo proceso que los demás componentes de ese contenedor. En un servicio Java puede ser un conjunto de clases detrás de una interfaz; en un servicio Node.js, un módulo. Los componentes no se pueden desplegar por separado; la unidad de despliegue es el contenedor. Por último, el código son las clases, funciones y tablas que implementan un componente.

Nivel 1: el diagrama de contexto del sistema

El diagrama de contexto del sistema es el punto de partida. Coloca el sistema que estás describiendo en el centro, como una sola caja, y lo rodea de las personas que lo usan y de los sistemas de software de los que depende o que dependen de él. Oculta deliberadamente todo el detalle interno, incluidas las tecnologías, los protocolos y los servicios internos. Responde a las preguntas que cualquier recién llegado, responsable de producto o revisor de seguridad hace primero: ¿qué es este sistema, quién lo usa y con qué se conecta?

Como oculta lo interno, el diagrama de contexto es también el diagrama adecuado para las conversaciones con partes interesadas no técnicas y para delimitar el alcance: ¿dónde termina nuestra responsabilidad? En el ejemplo de reparto de comida de abajo muestra de inmediato que los pagos con tarjeta, el cálculo de rutas y el envío de notificaciones push se contratan fuera, lo cual es arquitectónicamente significativo (cada uno es una dependencia externa con su propia disponibilidad, su costo y su contrato) e invisible en la mayoría de las vistas a nivel de código.

Nivel 2: el diagrama de contenedores

El diagrama de contenedores se acerca a la caja del sistema y muestra los contenedores que hay dentro: las aplicaciones y los almacenes de datos que forman el sistema, de qué es responsable cada uno, qué tecnología usa cada uno y cómo se comunican. Para la mayoría de los equipos es el diagrama más valioso que tienen. Muestra las principales decisiones estructurales (cuántas unidades desplegables hay, cuáles se comunican de forma síncrona y cuáles mediante mensajería, cuáles son dueñas de datos) y es lo bastante concreto para los desarrolladores y el personal de operaciones, sin dejar de caber en una página.

Fíjate en dos decisiones en el diagrama de abajo. El topic de mensajes de los eventos de pedidos se dibuja como un contenedor por derecho propio, porque es un almacén en el que los productores escriben y del que los consumidores leen; la guía de C4 ofrece este estilo explícito o, como alternativa, omitir el topic y escribir "a través del topic de eventos de pedidos" en las flechas. Dibujarlo muestra con claridad el acoplamiento a través del topic. Y las relaciones asíncronas usan una línea discontinua, que explica la leyenda. El diagrama de contenedores no dice nada sobre cuántas copias de cada servicio se ejecutan, en qué región o detrás de qué balanceador de carga; eso corresponde a un diagrama de despliegue.

Nivel 3: el diagrama de componentes

El diagrama de componentes se acerca a un contenedor y muestra los componentes que hay dentro. Está dirigido a los arquitectos y desarrolladores que trabajan en ese contenedor, y es donde se hace visible la estructura interna de un servicio: qué parte atiende las solicitudes entrantes, dónde viven las reglas de negocio, qué parte habla con la base de datos y cómo salen los eventos del servicio.

La guía de C4 es dibujar diagramas de componentes solo donde aporten valor, normalmente para contenedores complejos, arriesgados o que modifican muchas personas, y generarlos automáticamente si se van a mantener durante mucho tiempo, porque la estructura de componentes cambia tan a menudo como el código. En la plataforma de reparto de comida, el servicio de pedidos cumple esos requisitos: maneja dinero, habla con un proveedor externo y debe publicar eventos de forma fiable. El diagrama de abajo muestra una estructura típica, que incluye un componente de bandeja de salida (outbox) que escribe los eventos en la base de datos en la misma transacción que el pedido y después los retransmite a Kafka (el patrón de bandeja de salida se trata en el Capítulo 6).

Nivel 4: el código y los diagramas complementarios

El nivel de código se acerca a un componente y muestra sus clases, interfaces o tablas, normalmente como diagrama de clases UML o diagrama entidad-relación. La guía de C4 lo considera opcional y, en general, no vale la pena dibujarlo a mano: la mayoría de los entornos de desarrollo pueden generarlo bajo demanda, y una copia dibujada a mano queda desactualizada en cuanto alguien refactoriza. Dibújalo solo para las partes más importantes o intrincadas, como un modelo de dominio en el corazón del negocio (la Sección 4.4 muestra un diagrama de clases así).

Tres diagramas complementarios cubren los huecos que deja la jerarquía. Un diagrama de panorama de sistemas (system landscape) es un diagrama de contexto sin un único sistema en el foco: muestra todos los sistemas de software y personas de una organización o dominio, lo que resulta útil para los arquitectos empresariales y de plataforma. Un diagrama dinámico muestra cómo colaboran los elementos en tiempo de ejecución en un escenario, como interacciones numeradas sobre un diagrama de contenedores o de componentes (o como un diagrama de secuencia UML); es el equivalente en C4 de los escenarios de 4+1. Un diagrama de despliegue muestra cómo se asignan los contenedores a la infraestructura en un entorno: nodos de despliegue como regiones de la nube, clústeres de Kubernetes, máquinas virtuales, servicios de bases de datos gestionados y dispositivos, con el número de instancias. C4 recomienda un diagrama de despliegue por cada entorno que importe, normalmente producción y quizá preproducción (staging).

Reglas de notación que hacen legibles los diagramas

C4 no prescribe formas ni colores, pero sí prescribe lo que debe decir todo diagrama. Estas reglas, resumidas de la guía de notación de C4, son las que hacen que los diagramas anteriores se puedan leer sin una reunión para explicarlos.

Herramientas: dibujo frente a modelado

Los diagramas C4 pueden hacerse con cualquier herramienta de dibujo, y muchos equipos empiezan con una pizarra o una aplicación general de diagramas. El sitio de C4 distingue dos familias de herramientas. Las herramientas de diagramación dibujan cajas y líneas; son flexibles y conocidas, pero los diagramas son imágenes independientes, así que cambiar el nombre de un elemento obliga a editar todos los diagramas que lo muestran, y nada comprueba que los diagramas coincidan. Las herramientas de modelado mantienen un único modelo de personas, sistemas, contenedores, componentes y relaciones, y generan cada diagrama como una vista de ese modelo; el cambio de nombre se hace una sola vez, los diagramas siguen siendo coherentes y el modelo se puede consultar y validar.

Structurizr, creada por Simon Brown, es la herramienta de modelado de referencia para C4. Su Structurizr DSL, basado en texto, describe el modelo y las vistas en un archivo que vive en el control de versiones junto al código. Otras opciones son C4-PlantUML (formas C4 para PlantUML), el soporte de diagramas C4 de Mermaid y diversas herramientas de modelado comerciales; la Sección 4.7, Diagramas como código, muestra ejemplos. La elección importa menos que el hábito: guarda la fuente de los diagramas donde trabaja el equipo y actualízala en el mismo pull request que el cambio que describe.