Qu'est-ce que le modèle C4 ?

Le modèle C4 est un jeu de quatre diagrammes sur un même système, chacun plus rapproché que le précédent. Son apport réel n'est pas le dessin, c'est l'ordre. Chaque niveau répond à une question, et cette réponse soulève la question pour laquelle existe le niveau suivant.

Le public se rétrécit à mesure que vous descendez. Le niveau 1 s'adresse à quiconque s'intéresse au système, y compris à des gens qui ne liront jamais de code. Le niveau 4 s'adresse à l'équipe, la semaine où elle restructure quelque chose. Ce gradient est l'argument pour dessiner les deux premiers et s'arrêter jusqu'à ce que quelqu'un en demande plus.

C'est la partie qui se perd. C4 ne définit ni formes, ni styles de trait, ni sémantique de relation. Il vous dit ce qui a sa place sur chaque diagramme et à qui il s'adresse, puis : dessinez-le comme votre équipe dessine déjà.

La conséquence pratique est que C4 se compose avec la notation que vous avez au lieu de la remplacer. Un diagramme de conteneurs dessiné avec des composants UML est à la fois un diagramme UML légal et un diagramme C4 correct. Dessiné en ArchiMate, le même contenu se projette sur des composants applicatifs et des noeuds technologiques. Les deux conviennent. Ce qui ne convient pas, c'est un diagramme dont les boîtes signifient trois choses différentes parce que personne n'a dit de quel niveau il s'agissait.

Comme il n'y a pas de notation à vérifier, la discipline doit venir d'ailleurs : étiquetez chaque boîte par ce qu'elle est, chaque trait par ce qu'il fait et sur quel protocole, et ne mélangez jamais deux niveaux sur une même toile. Ces trois règles font l'essentiel du travail qu'une spécification ferait autrement à votre place.

C4 est antérieur à la domination de Docker et emploie conteneur dans son sens ancien et général : une chose qui doit tourner pour que le système fonctionne, et qui peut être déployée seule. Une application monopage est un conteneur. Une base de données aussi, comme une fonction serverless, un courtier de messages et une application mobile.

Le niveau 2 est celui qui apporte le plus, et c'est celui que les équipes sautent - en partie à cause du nom, en partie parce que c'est le premier diagramme qui force une vraie décision sur ce qu'est réellement le système. L'article sur le diagramme de conteneurs en déroule un de bout en bout.

Un jeu de diagrammes C4 a le même mode de défaillance que toute autre documentation d'architecture : exact le jour où il est dessiné, discrètement faux six mois plus tard. Deux choses aident, et aucune ne concerne le dessin.

La première est de garder les niveaux dans un seul modèle plutôt que dans quatre images sans lien. Si l'API de votre diagramme de contexte et celle de votre diagramme de conteneurs sont le même élément, la renommer est une seule modification ; si ce sont deux boîtes qui partagent par hasard une étiquette, ce sont deux modifications et l'une sera oubliée. C'est l'argument en faveur d'un modèle derrière les vues, et c'est le même argument que développe longuement maintenir un modèle à jour.

La seconde est de dessiner moins de niveaux. Un diagramme de contexte et un diagramme de conteneurs qui sont vrais valent mieux que quatre niveaux dont deux sont de la fiction. Le niveau 4 en particulier devrait être généré depuis le code ou omis : un diagramme de classes dessiné à la main est l'instantané d'une opinion, et le compilateur en a une plus récente.