¿Qué es el modelo C4?

El modelo C4 es un conjunto de cuatro diagramas sobre un mismo sistema, cada uno más cercano que el anterior. Su aportación real no es el dibujo, es el orden. Cada nivel responde a una pregunta, y esa respuesta plantea la pregunta para la que existe el nivel siguiente.

El público se estrecha según bajas. El nivel 1 es para cualquiera con interés en el sistema, incluida gente que nunca leerá código. El nivel 4 es para el equipo, en una semana en la que está reestructurando algo. Ese gradiente es el argumento para dibujar los dos primeros y parar hasta que alguien pida más.

Esta es la parte que se pierde. C4 no define formas, estilos de línea ni semántica de relaciones. Te dice qué corresponde a cada diagrama y para quién es, y luego: dibújalo como tu equipo ya dibuja las cosas.

La consecuencia práctica es que C4 se compone con la notación que ya tienes en lugar de sustituirla. Un diagrama de contenedores dibujado con componentes UML es a la vez un diagrama UML legal y un diagrama C4 correcto. Dibujado en ArchiMate, el mismo contenido se proyecta sobre componentes de aplicación y nodos tecnológicos. Ambas cosas están bien. Lo que no está bien es un diagrama cuyas cajas significan tres cosas distintas porque nadie dijo de qué nivel se trataba.

Como no hay notación que comprobar, la disciplina tiene que venir de otro sitio: etiqueta cada caja con lo que es, cada línea con lo que hace y por qué protocolo, y no mezcles nunca dos niveles en un mismo lienzo. Esas tres reglas hacen casi todo el trabajo que de otro modo haría una especificación por ti.

C4 es anterior al dominio de Docker y usa contenedor en su sentido antiguo y general: algo que tiene que estar en marcha para que el sistema funcione y que puede desplegarse por su cuenta. Una aplicación de una sola página es un contenedor. También lo son una base de datos, una función serverless, un broker de mensajes y una aplicación móvil.

El nivel 2 es donde está casi todo el valor, y es el nivel que los equipos se saltan: en parte por el nombre y en parte porque es el primer diagrama que fuerza una decisión real sobre qué es el sistema en realidad. El artículo del diagrama de contenedores recorre uno de principio a fin.

Un conjunto de diagramas C4 tiene el mismo modo de fallo que cualquier otra documentación de arquitectura: es exacto el día en que se dibuja y calladamente falso seis meses después. Ayudan dos cosas, y ninguna va de dibujar.

La primera es mantener los niveles en un solo modelo en vez de en cuatro dibujos sin relación. Si la API de tu diagrama de contexto y la de tu diagrama de contenedores son el mismo elemento, renombrarla es una edición; si son dos cajas que casualmente comparten etiqueta, son dos ediciones y una se olvidará. Ese es el argumento a favor de un modelo detrás de las vistas, y es el mismo argumento que desarrolla en extenso mantener un modelo al día.

La segunda es dibujar menos niveles. Un diagrama de contexto y uno de contenedores que sean ciertos valen más que cuatro niveles de los que dos son ficción. El nivel 4 en particular debería generarse desde el código o dejarse fuera: un diagrama de clases dibujado a mano es la instantánea de una opinión, y el compilador tiene una más reciente.