Le modèle C4 : contexte, conteneurs, composants et code

Des cartes de votre code

Le modèle C4 est une approche de la représentation de l’architecture logicielle en diagrammes, créée par Simon Brown. Il est issu des formations en architecture logicielle qu’il donnait depuis 2006 environ : selon le site du C4, ses origines remontent à une période située entre 2006 et 2009, les types de diagrammes ont été nommés début 2010 et le nom « C4 » a été employé pour la première fois début 2011. Brown avait remarqué que les équipes à qui l’on demandait de dessiner leur architecture produisaient des diagrammes difficiles à comprendre : des formes et des couleurs inexpliquées, des boîtes qui pouvaient représenter n’importe quoi, d’une classe à un centre de données, des lignes sans libellé et plusieurs niveaux de détail mélangés sur une même page. UML, qui aurait pu résoudre le problème, était en grande partie sorti de l’usage quotidien.

Sa réponse n’a pas été une nouvelle notation, mais un petit ensemble d’abstractions et une hiérarchie de diagrammes construite sur elles, qu’il compare aux niveaux de zoom d’une carte en ligne. Vous commencez par le pays entier, zoomez sur une ville, puis sur un quartier, puis sur une rue. Chaque niveau montre une quantité de détail différente dans un but différent, et vous savez toujours quel niveau vous regardez. C4 est délibérément indépendant de toute notation et de tout outil : vous pouvez le dessiner sur un tableau blanc, dans un outil de dessin ou avec un outil de modélisation, à condition de suivre quelques règles.

C4 est devenu l’une des approches les plus répandues pour les diagrammes d’architecture, parce qu’il est facile à apprendre, qu’il s’accorde naturellement avec la réflexion à plusieurs vues de la section 4.2 et qu’il produit des diagrammes que les développeurs comme les lecteurs non techniques peuvent suivre. Dans les termes de 42010, chaque type de diagramme C4 est un point de vue doté de son propre type de modèle ; C4 se contente de garder cet ensemble restreint.

Les abstractions : personnes, systèmes logiciels, conteneurs, composants

C4 repose sur quatre abstractions, plus le code. Une personne est un utilisateur humain du système : un client, un livreur, un agent du support. Un système logiciel est le niveau d’abstraction le plus élevé, quelque chose qui apporte de la valeur à ses utilisateurs et qui est généralement détenu et construit par une seule équipe ou organisation ; la plateforme de livraison de repas en est un, tout comme le prestataire de paiement et le service de cartographie dont elle dépend.

Un conteneur est quelque chose qui doit être en cours d’exécution pour que le système fonctionne : selon les mots de Brown, il s’agit essentiellement d’une frontière d’exécution autour d’un code qui est exécuté ou de données qui sont stockées. Par exemple : une application web côté serveur, une application monopage qui s’exécute dans un navigateur, une application mobile, une application de bureau, une fonction serverless, un schéma de base de données, un stockage de fichiers ou un topic de messages. Chacun est déployable ou exécutable séparément, et les conteneurs communiquent entre eux au-delà des frontières de processus, généralement par un réseau.

Un composant est un regroupement de fonctionnalités liées derrière une interface bien définie, qui vit à l’intérieur d’un conteneur et s’exécute dans le même processus que les autres composants de ce conteneur. Dans un service Java, ce peut être un ensemble de classes derrière une interface ; dans un service Node.js, un module. Les composants ne sont pas déployables séparément ; le conteneur est l’unité de déploiement. Enfin, le code désigne les classes, les fonctions et les tables qui implémentent un composant.

Niveau 1 : le diagramme de contexte système

Le diagramme de contexte système est le point de départ. Il place le système que vous décrivez au centre, sous forme d’une seule boîte, et l’entoure des personnes qui l’utilisent et des systèmes logiciels dont il dépend ou qui dépendent de lui. Il masque délibérément tout détail interne, y compris les technologies, les protocoles et les services internes. Il répond aux questions que posent en premier tout nouvel arrivant, tout chef de produit et toute personne chargée de la revue de sécurité : qu’est-ce que ce système, qui l’utilise et à quoi est-il connecté ?

Parce qu’il masque l’intérieur, le diagramme de contexte est aussi le bon diagramme pour les discussions avec les parties prenantes non techniques et pour délimiter le périmètre : où s’arrête notre responsabilité ? Dans l’exemple de livraison de repas ci-dessous, il montre immédiatement que le paiement par carte, le calcul d’itinéraires et l’envoi des notifications push sont achetés à l’extérieur, ce qui est architecturalement significatif (chacun est une dépendance externe, avec sa propre disponibilité, son propre coût et son propre contrat) et invisible dans la plupart des vues au niveau du code.

Niveau 2 : le diagramme de conteneurs

Le diagramme de conteneurs zoome sur la boîte du système et montre les conteneurs qu’elle contient : les applications et les stockages de données qui composent le système, la responsabilité de chacun, la technologie que chacun utilise et la façon dont ils communiquent. Pour la plupart des équipes, c’est le diagramme le plus précieux dont elles disposent. Il montre les grandes décisions structurelles (combien d’unités déployables, lesquelles communiquent de façon synchrone et lesquelles par messagerie, lesquelles possèdent des données) et il est suffisamment concret pour les développeurs et les équipes d’exploitation, tout en tenant sur une seule page.

Remarquez deux choix dans le diagramme ci-dessous. Le topic de messages des événements de commande est dessiné comme un conteneur à part entière, car c’est un stockage dans lequel les producteurs écrivent et que les consommateurs lisent ; les recommandations C4 proposent ce style explicite ou, à défaut, d’omettre le topic et d’écrire « via le topic des événements de commande » sur les flèches. Le dessiner montre clairement le couplage qui passe par le topic. Par ailleurs, les relations asynchrones utilisent une ligne en pointillés, que la légende explique. Le diagramme de conteneurs ne dit rien du nombre de copies de chaque service en cours d’exécution, de leur région ni de l’équilibreur de charge derrière lequel elles se trouvent ; cela relève d’un diagramme de déploiement.

Niveau 3 : le diagramme de composants

Le diagramme de composants zoome sur un conteneur et montre les composants qu’il contient. Il s’adresse aux architectes et aux développeurs qui travaillent sur ce conteneur, et c’est là que la structure interne d’un service devient visible : quelle partie traite les requêtes entrantes, où vivent les règles métier, quelle partie communique avec la base de données, comment les événements sortent du service.

Les recommandations C4 consistent à ne dessiner des diagrammes de composants que là où ils apportent de la valeur, généralement pour les conteneurs complexes, risqués ou modifiés par de nombreuses personnes, et à les générer automatiquement s’ils doivent être conservés longtemps, car la structure des composants change aussi souvent que le code. Pour la plateforme de livraison de repas, le service des commandes remplit ces conditions : il manipule de l’argent, communique avec un prestataire externe et doit publier des événements de façon fiable. Le diagramme ci-dessous montre une structure typique, y compris un composant outbox qui écrit les événements dans la base de données au sein de la même transaction que la commande, puis les relaie vers Kafka (le patron outbox est traité au chapitre 6).

Niveau 4 : le code, et les diagrammes complémentaires

Le niveau du code zoome sur un composant et montre ses classes, ses interfaces ou ses tables, généralement sous forme de diagramme de classes UML ou de diagramme entité-association. Les recommandations C4 le considèrent comme facultatif et comme ne valant généralement pas la peine d’être dessiné à la main : la plupart des environnements de développement peuvent le générer à la demande, et une copie dessinée à la main est périmée dès que quelqu’un refactorise. Ne le dessinez que pour les parties les plus importantes ou les plus complexes, comme un modèle de domaine au cœur du métier (la section 4.4 montre un tel diagramme de classes).

Trois diagrammes complémentaires comblent les lacunes laissées par la hiérarchie. Un diagramme de paysage système est un diagramme de contexte sans système unique au centre : il montre tous les systèmes logiciels et toutes les personnes d’une organisation ou d’un domaine, ce qui est utile aux architectes d’entreprise et de plateforme. Un diagramme dynamique montre comment les éléments collaborent à l’exécution pour un scénario, sous forme d’interactions numérotées sur un diagramme de conteneurs ou de composants (ou sous forme de diagramme de séquence UML) ; c’est l’équivalent C4 des scénarios du modèle 4+1. Un diagramme de déploiement montre comment les conteneurs sont placés sur l’infrastructure dans un environnement : des nœuds de déploiement comme des régions cloud, des clusters Kubernetes, des machines virtuelles, des services de base de données managés et des appareils, avec le nombre d’instances. C4 recommande un diagramme de déploiement par environnement important, généralement la production et éventuellement le staging.

Des règles de notation qui rendent les diagrammes lisibles

C4 n’impose ni formes ni couleurs, mais il impose ce que chaque diagramme doit dire. Ces règles, condensées à partir des recommandations de notation C4, sont ce qui rend les diagrammes ci-dessus lisibles sans réunion pour les expliquer.

Outils : dessin ou modélisation

Les diagrammes C4 peuvent être produits avec n’importe quel outil de dessin, et de nombreuses équipes commencent par un tableau blanc ou une application générique de création de diagrammes. Le site du C4 distingue deux familles d’outils. Les outils de diagrammes dessinent des boîtes et des lignes ; ils sont souples et familiers, mais les diagrammes sont des images indépendantes : renommer un élément oblige à modifier chaque diagramme qui le montre, et rien ne vérifie que les diagrammes concordent. Les outils de modélisation contiennent un modèle unique des personnes, des systèmes, des conteneurs, des composants et des relations, et génèrent chaque diagramme comme une vue de ce modèle ; le renommage se fait une seule fois, les diagrammes restent cohérents et le modèle peut être interrogé et validé.

Structurizr, créé par Simon Brown, est l’outil de modélisation de référence pour C4. Son langage textuel, le Structurizr DSL, décrit le modèle et les vues dans un fichier qui vit dans le système de gestion de versions, à côté du code. Parmi les autres options figurent C4-PlantUML (des formes C4 pour PlantUML), la prise en charge des diagrammes C4 par Mermaid et divers outils de modélisation commerciaux ; la section 4.7, Diagrammes en tant que code, en montre des exemples. Le choix compte moins que l’habitude : gardez la source des diagrammes là où l’équipe travaille, et mettez-la à jour dans la même pull request que le changement qu’elle décrit.