¿Cómo definir la arquitectura de tu sistema con C4 Model?
Aunque en este mundo Agile a veces se menosprecia la importante de la arquitectura software de una sistema, podríamos decir que en este mundo de microservicios, contenedores, Kubernetes, Cloud y servicios es crucial para responder a preguntas sobre la seguridad de mi sistema, la integración con otros sistemas, etc.
Por otro lado, documentar la arquitectura de un proyecto es un proceso complejo y minucioso que requiere tiempo, conocimiento de herramientas y técnicas de diagramación y documentación.
Existen varios modelos para definir la arquitectura; algunos auténticos clásicos como el modelo 4+1 (uno de nuestros favoritos junto al SunTone AM). En este artículo vamos a hablar sobre el Modelo C4 para definir la arquitectura de un sistema.
Dicho esto, el objetivo del C4 Model consiste en evitar 2 cosas:
- Que la documentación de la arquitectura sea compleja, confusa y que al final acabe obsoleta, con lo que pierde su finalizad principal.
- Que la documentación sea pobre, con poca información o con información incorrecta, que no nos lleva tiempo crear, pero que es inútil.
Qué es C4 Model
El Modelo C4 es un formato de documentación creado por el ingeniero Simon Brown entre 2006 y 2011, y basado en los modelos 4+1 y UML.
Este modelo surgió para ayudar a resolver el problema de la documentación defectuosa de arquitecturas, difíciles de entender y mantener. El modelo C4 aclara la arquitectura documentada y abarca varios niveles relevantes para las distintas «personas» implicadas.
Los niveles de C4 Model
El modelo C4 tiene cuatro tipos de diagramas, cada uno de los cuales tiene un nivel de detalle y un público objetivo diferentes. La idea es profundizar en los detalles y la información de la historia anterior (como haciendo zoomo)
En el modelo C4 encontramos los siguientes niveles:
- Context/Contexto
- Container/Contenedor
- Component/Componente
- Code/Código
Seguidamente vamos a ver cada uno de los niveles sobre un ejemplo documentado con C4 Model, el «Horusec C4Model», donde Horusec es una herramienta de código abierto que realiza un análisis estático del código para identificar fallos de seguridad durante el proceso de desarrollo.
Nivel 1: Contexto
Es el primer paso de nuestro diseño. La idea es mostrar las interacciones de forma macro, sin mucho detalle, centrándose en las comunicaciones y dependencias entre los sistemas y los usuarios que componen e interactúan con el software.
Es un diagrama que puede (y debe) ser consumido por todas las «personas» del proyecto, tanto técnicas como de negocio, y que interactúan directa o indirectamente con el sistema.
Veamos el diagrama para el ejemplo:
Nivel 2: Contenedor
El segundo nivel muestra el sistema con más detalle, describiendo sus contenedores (no confundir con Docker) y cómo se comunican/interactúan. En este nivel, se hace hincapié en la arquitectura y las tecnologías utilizadas.
La idea es mostrar cómo se construye (o se construirá) el sistema de forma macro. Un contenedor puede ser una aplicación web, una base de datos, un sistema de archivos, entre otros. Es un diagrama para ser consumido por el equipo técnico, que interactúa directa o indirectamente con el sistema (profesionales de desarrollo, de soporte, etc.).
En el ejemplo tenemos:
Nivel 3: Componente
Al llegar al tercer nivel, se da un paso más en los detalles respecto al contenedor, esta vez con la descripción de las partes que lo componen. En este nivel, la información sobre las interacciones, las responsabilidades y las tecnologías utilizadas aparece con más detalle que en los niveles anteriores.
Es probable que un sistema tenga más de un diagrama de componentes. Es un diagrama para ser consumido por el equipo de desarrollo técnico, que se recomienda sólo en los casos que han generado valor. Existe el compromiso de mantenerlo.
En nuestro ejemplo tenemos 4 diagramas:
Podemos encontrar toda la información desde: C3-Component (horusec.io).
Nivel 4: Código
En el último nivel, el modelo C4 muestra -a nivel de código- cómo se implementa cada componente y para ello utiliza el diagrama de clases UML.
En general, este nivel de detalle no se recomienda y es una vista opcional. Además, varias herramientas generan actualmente este tipo de diagrama de forma automática.
Herramientas para C4 Model
Una herramienta muy potentes es el C4Builder que permite definir la arquitectura en diferentes formatos (como plantuml o md) y exportar los documentos de arquitectura.
C4Builder se basa en estas herramientas:
- PlantUml crea diagramas a partir de texto plano.
- Markdown crea documentos de texto enriquecido a partir de texto vegetal.
- C4Model la idea detrás de los mapas del código.
- C4-PlantUML Soporte de la sintaxis C4 para generar diagramas plantuml.
- Docsify crea un sitio de una sola página basado en archivos markdown.
- vscode-plantuml plugin para Visual Studio Code para ver los diagramas en tiempo de diseño.
Ejemplos C4 Model
Estos ejemplos pueden daros una idea de cómo se define una arquitectura con un Modelo C4:
✍🏻 Author(s)
