- Le modèle C4 est une approche adaptée aux développeurs pour créer des diagrammes d’architecture logicielle, permettant d’examiner des structures complexes étape par étape
- L’abstraction descend dans l’ordre software systems → containers → components → code, en traitant l’architecture de manière hiérarchique
- Les diagrammes sont également organisés selon la structure system context → container → component → code
- Selon les besoins, des diagrammes system landscape, dynamic et deployment complètent la vue d’ensemble ainsi que les perspectives d’exécution et de déploiement
- Comme il s’agit d’une approche notation independent et tooling independent, non liée à une notation ou à un outil spécifique, elle peut être appliquée à un environnement existant
Composition du modèle C4
- Le modèle C4 est un modèle destiné à visualiser l’architecture logicielle, créé par Simon Brown
- Son principe central consiste à utiliser ensemble une abstraction hiérarchique et des diagrammes hiérarchiques
Diagrammes et indépendance
- Les diagrammes de base sont conçus pour permettre de voir l’architecture à différents niveaux de profondeur
- Les diagrammes complémentaires ajoutent les perspectives que les seuls niveaux de base ne suffisent pas à couvrir
- Le modèle est notation independent et tooling independent, et n’impose donc pas de notation ni de choix d’outil particulier
- Parmi les ressources associées figurent la vidéo Visualising software architecture with the C4 model, enregistrée en juillet 2019 lors de « Agile on the Beach 2019 », ainsi que le document The C4 model
1 commentaires
Avis de Hacker News
À mon avis, le plus gros problème des diagrammes d’architecture est qu’ils divergent de la base de code.
Ce type de diagramme devrait être généré automatiquement. Sinon, l’équipe n’a aucun moyen de savoir si le schéma qu’elle regarde représente correctement l’état actuel du système.
Un diagramme montre un point de vue particulier, met en avant certaines caractéristiques et en omet d’autres. Pour un même objet, il peut exister plusieurs diagrammes décrivant différents aspects ou scénarios. Au final, comme les documents texte, les diagrammes doivent être maintenus avec le code et l’architecture de l’application ; il n’y a pas d’autre choix que d’en faire une tâche régulière de gestion des changements.
Dans beaucoup de projets, le code n’est pas organisé de la même manière que le modèle mental, et presque aucun langage ne fournit de moyen d’y remédier. Marquer cela avec des commentaires dans le code pose le même problème que de garder à jour les diagrammes, les commentaires et la documentation.
Ils représentent non pas l’état actuel, mais l’état cible. Le code doit suivre le diagramme, pas l’inverse. Générer un diagramme à partir du code n’a vraiment de sens que pour aider une personne qui rejoint un projet sans documentation ; même dans ce cas, on le génère une fois, puis on l’épure en retirant le bruit, avant de l’utiliser comme document de référence.
Les diagrammes de haut niveau doivent pouvoir être créés et jetés rapidement, et ce qu’ils omettent est aussi important que ce qu’ils montrent.
J’aime bien C4. Avant, je trouvais inutiles les diagrammes de contexte du genre « User -{do their job}-> System-of-Record », mais maintenant j’en comprends la raison.
Nous travaillons avec des équipes étendues sur une nouvelle conception d’un système complexe en utilisant C4. En dessinant cette fois le schéma de plus haut niveau, nous nous sommes rendu compte qu’en plus de l’interface web, il existe une application mobile susceptible d’être partiellement déconnectée ; il faut donc dégrader élégamment certains comportements si elle est hors ligne, si le backend est lent ou si certains résultats ne sont pas encore disponibles. Au niveau suivant, cela a conduit à une file de tâches, puis de nouveau à l’UX, ce qui nous a permis de dire clairement quelles requêtes pouvaient prendre un temps indéfini à se terminer. Nous y serions sans doute arrivés un jour, mais l’analyse a mis ce problème au premier plan. Tout cela parce qu’il fallait dessiner « Remote-User --{Mobile Stuff}--> Backend ». Peu importe l’outil utilisé ; pour ma part, par exemple, j’utilise draw.io avec des onglets séparés par niveau. Quand ce sera plus détaillé, je séparerai les niveaux inférieurs dans des fichiers distincts.
Je comprends aussi l’argument selon lequel les diagrammes n’ont pas besoin d’un système formalisé, mais je trouve que C4 reste assez léger. Je ne descends pas jusqu’au niveau du code.
Cela dit, structurizr, qui produit des diagrammes C4, a fortement amélioré ma productivité. La possibilité de générer, à partir d’un seul modèle, plusieurs vues à différents niveaux de détail est excellente par rapport à mermaid ou plantuml, où chaque diagramme doit définir et redéfinir indépendamment les mêmes composants. Le flux consistant à créer une branche, modifier le modèle et présenter une idée m’a très bien convenu.
Il n’y avait aucun moyen de représenter des concepts qui n’appartiennent pas strictement à C4. Par exemple, je voulais placer deux composants dans une même boîte pour montrer qu’ils sont actuellement déployés comme un seul service, mais c’était impossible. Cela ne veut pas dire que c’est une conception absolument bonne, mais cela aurait aidé l’équipe à comprendre. L’idée de décrire formellement l’architecture est bonne, mais le manque de personnalisation du rendu des diagrammes était vraiment pénible.
On décrit l’architecture, puis structurizr rend les diagrammes.
C’est possible, mais assez laborieux, et dès que les descriptions des flèches entre les boîtes deviennent longues, la mise en page automatique s’effondre rapidement.
J’ai tendance à considérer l’architecture logicielle comme un ensemble de décisions de conception qui guident l’implémentation
D’après mon expérience, la plupart des architectes logiciels donnent des orientations et une structure aux ingénieurs logiciels. Mais la formulation de C4, « créer une carte du code existant à différents niveaux de détail », sonne différemment. Je ne comprends pas pourquoi on appelle des diagrammes de code de l’architecture logicielle. C’est littéralement au niveau du code ; en quoi est-ce de l’architecture ? C’est un peu comme vouloir mettre le schéma électrique d’une prise dans les plans d’une maison. Si « il faut utiliser des outils d’automatisation », est-ce qu’on parle de documenter une base de code existante fonction par fonction ? Je ne vois pas en quoi cela aide à concevoir et planifier un logiciel. Une carte décrivant la structure d’un logiciel existant peut être intéressante, mais quand on parle de design patterns, on ne fournit pas une carte fonction par fonction de l’implémentation d’un singleton. Il suffit de dire qu’il faut un singleton ou un repository pattern. La conception logicielle existe clairement, et cette approche paraît valable pour la conception, mais d’après mon expérience, conception, implémentation et architecture logicielles ne sont pas la même chose, et ne sont pas non plus faites par les mêmes personnes. Cela ressemble davantage à de la conception système, et j’imagine que l’architecte logiciel aurait plutôt pour rôle de conseiller afin que cette conception système respecte de bons principes d’architecture. Je pinaille peut-être trop
Selon moi, un rôle essentiel de l’architecture logicielle est de fournir aux développeurs les informations qui leur permettent de prendre eux-mêmes des décisions de conception, sans devoir s’en remettre à chaque fois à une autorité. Cela dit, la frontière entre architecture et développement varie beaucoup. Je pense que l’architecture elle-même détermine ce qui est important du point de vue architectural. Si l’architecture considère qu’un détail applicatif de bas niveau est important, alors ce détail devient aussi un détail architectural. Dans la plupart des organisations, l’architecture contrôle au minimum la conception de haut niveau : composants, schémas de communication, API, technologies utilisées. Dans certaines organisations, elle descend jusqu’aux classes individuelles. Pas toutes les classes, mais celles qui modélisent le domaine métier, surtout lorsque ce modèle sert de langage à plusieurs projets ou est implémenté comme livrable partagé. C4 convient aux organisations qui considèrent que l’architecture ne s’arrête pas à la liste des applications et des interfaces d’intégration, mais inclut aussi des structures de plus bas niveau
En gros, il s’agit d’avoir un diagramme pour chaque niveau clairement distinct ou utile du système. Si vous avez besoin d’un diagramme au niveau du code, c’est probablement que vous faites un travail sur mesure complexe, ou que vous spécifiez excessivement une conception qui pourrait rester un détail d’implémentation
C’est un peu comme dans la construction immobilière réelle, où les rôles de l’architecte, de l’ingénieur et du chef de chantier sont différents. Je me demande où il faut tracer la ligne entre architecture, conception et implémentation, et quelles préoccupations chacune doit traiter
C’est intéressant, mais il est difficile d’y voir quelque chose de vraiment nouveau
Les diagrammes de haut niveau sont utiles, mais on peut déjà en faire sans lire un beau site web de modèle visuel. Le site le reconnaît d’ailleurs pratiquement lui-même. Il est très juste de dire que l’industrie dispose d’UML, d’ArchiMate et de SysML, mais que beaucoup d’équipes choisissent des diagrammes « boîtes et lignes » beaucoup plus simples. En revanche, il semble ignorer pourquoi les diagrammes de classes UML ont complètement échoué. Il reconnaît que personne ne les aime, mais le quatrième C du modèle, le code, revient finalement à un diagramme de classes UML. On n’a pas besoin de ça. Il suffit de dessiner clairement un diagramme quelconque et de mettre des libellés sur les flèches. Les trois premiers diagrammes en sont d’ailleurs de bons exemples
C’est très utile aussi quand on réfléchit à un nouveau concept ou qu’on fait du brainstorming, parce que l’outil ne se met pas en travers. En ce moment j’utilise Freeform : c’est très simple, mais ça fonctionne bien. Il suffit de sélectionner deux objets puis de faire cmd-clic ou clic droit et « add connecting line »
Il y a seulement quelques mois, j’ai encore finalisé un document d’architecture contenant pas mal de diagrammes de classes, de diagrammes de séquence et de cas d’utilisation
Les boîtes finissent facilement par mélanger des choses de niveaux différents. Certaines sont abstraites, d’autres concrètes, d’autres simplement arbitraires. Du coup, si l’on doit assembler un morceau d’architecture plus large, par exemple une chaîne d’approvisionnement, il faut pratiquement tout refaire. C’est très gaspilleur, et comme personne ne voit suffisamment clairement l’architecture d’ensemble, cela entraîne d’autres gaspillages et problèmes de qualité. Curieusement, beaucoup d’ingénieurs réagissent de façon défensive aux approches plus formelles, probablement parce qu’ils n’en voient pas le bénéfice immédiat ou n’ont jamais eu à gérer une architecture à grande échelle, donc ne voient pas le problème
Cela montre que le génie logiciel est encore un domaine immature
Dans mon cas, cela fait plus de 25 ans, et nous avons toujours à peu près les mêmes discussions « de base ». Je ne dis pas que c’est mauvais, mais les progrès sont lents, et on ne peut pas seulement en rejeter la faute sur une entreprise, un consortium ou des intérêts commerciaux particuliers
Combien de fois quelqu’un oscille-t-il sans cesse, au sein d’une même idée, entre un niveau de détail élevé, une forte complexité et une simplicité vue de loin, au point qu’il devient difficile de comprendre ce qu’il veut dire ? Le même problème apparaît quand un développeur pense : « il suffit de dessiner quelques boîtes et flèches sur ce tableau, ça a du sens dans ma tête donc c’est un bon diagramme »
Même sans être ingénieur civil, on comprend immédiatement quelque chose comme un plan d’étage et on le trouve utile
Mais même en tant qu’ingénieur logiciel professionnel, ces diagrammes d’exemple ne me semblent pas assez utiles ni assez informatifs pour justifier l’effort. Le code est trop multidimensionnel pour être correctement approximé par une image en deux dimensions, et cela fonctionne mal. Ce qui a du potentiel, ce sont des patterns de code d’architecture plus conventionnels. Quelque chose comme la concurrence structurée, et peut-être quelque chose d’encore plus haut niveau
Le contexte d’un plan d’étage est très fixe et sa portée limitée. Par exemple, il n’est pas nécessaire d’expliquer ce qu’est une fenêtre. Mais dans le logiciel, il faut la plupart du temps réellement expliquer la « fenêtre ». Comme toutes les « fenêtres », ou tous les éléments, sont différents les uns des autres, on ne peut pas simplement dire que ceci est une fenêtre et le copier vingt fois
Si le modèle C4 vous semble trop arbitraire et excessivement spécifié, j’ai écrit plus tôt cette année au sujet d’une pratique alternative : https://www.ilograph.com/blog/posts/concrete-diagramming-mod...
J’aime bien ce modèle, et il m’est aussi arrivé de devoir utiliser UML pour des architectures de sécurité. Dans ce domaine, la cohérence depuis le contexte de plus haut niveau jusqu’au code est essentielle.
La simplicité du modèle C4 est une forme de contrainte. S’il existe un contexte ou un composant caché, il doit apparaître dans le modèle. S’il y a de la résistance même face à quelque chose d’aussi simple, j’y vois le signe qu’il pourrait y avoir des éléments cachés. Dans les grands projets, il y en a généralement. Amener les gens à clarifier leur pensée de cette manière les oblige à s’engager sur des affirmations et des idées, au lieu de simplement se réserver le droit de proposer et de critiquer, ce qui répartit l’autorité. Cela peut aussi susciter beaucoup de résistance. Mais ce n’est pas un problème du modèle : c’est ce qui se produit quand le modèle rencontre les gens. Comme j’apprécie cette cohérence, je pense que j’utiliserais cette approche comme référence pour la conception de sécurité.
C4 est très intéressant et, à mon avis, traite bien un problème précis de l’architecture logicielle.
Il relègue les couches basses de l’architecture — principalement le matériel et le logiciel système — à de grandes abstractions, et permet de concentrer l’effort sur ce qui se trouve plus haut dans la pile. Il correspond étonnamment bien aux approches actuelles cloud, conteneurisées et extensibles. Dans le même esprit, ArchiMate est également intéressant et recoupe beaucoup de choses, mais il est plus solidement ancré côté infrastructure. Par le passé, j’ai utilisé une approche de diagrammes proche d’ArchiMate pour réduire les conflits entre systèmes et sources de données, et pour montrer comment les briques que nous achetions et assemblions répondaient à des besoins précis de l’entreprise et des workflows utilisateurs ; cela s’est révélé très efficace. Dire que ces artefacts divergent de la base de code est tout à fait juste. Mais lorsqu’il faut analyser un système complexe, ou communiquer un système et des plans à un groupe plus large, ce sont d’excellents outils. Il est étonnamment fréquent qu’il n’existe aucune documentation cohérente, et le simple fait de passer quelques semaines à dessiner des boîtes et des traits peut débloquer et simplifier un travail frustrant qui n’avançait pas. C’est particulièrement vrai lorsque plusieurs équipes travaillent sur le même périmètre. C4, ArchiMate, UML, etc. ne sont que des langages de diagrammes contraints, destinés à capturer certains éléments précis que l’on veut communiquer, analyser ou consigner. Je ne pense pas qu’ils soient très bons comme outils de planification ou de conception en amont. Beaucoup de gens ont souffert à l’époque de la grande mode UML. On en était à penser qu’une organisation d’architectes en chef devait définir péniblement tous les aspects du système, jusqu’aux définitions de classes, avant qu’une seule ligne de code ne soit écrite, et des délires comme « il suffit de générer le code à partir des diagrammes » ont fait souffrir énormément de monde. Une fois le codage réel commencé, ces milliers d’heures de planification étaient généralement ignorées, et les développeurs finissaient par faire ce qu’ils voulaient.