[DevLille 2024] Structurizr DSL : Au-delà des diagrammes vers l'Architecture-as-Code
Cet article est un extrait de la conférence que j’ai donnée lors du DevLille, en juin 2024. Elle présentait le modèle C4 et son implémentation avec Structurizr pour produire de l’architecture-as-code.
Introduction
Nous avons tous hérité un jour du Tableau blanc avec plein de flêches :
un schéma complexe, tracé pendant un sprint héroïque, puis recouvert de poussière.
Personne n’ose l’effacer, de peur de perdre une information importante, mais plus personne ne s’y fie vraiment.
C’est le syndrome de la “documentation qui pourrit” : dès qu’un diagramme est exporté en PNG et figé dans un wiki, il commence à diverger du code.
Cette dette documentaire n’est pas une fatalité. L’idée est de passer du dessin jetable à une donnée durable.
Cessez de dessiner, commencez à modéliser
La différence entre “dessiner” et “modéliser” compte beaucoup, et c’est souvent là que le piège se referme.
Avec Miro, Lucidchart ou, soyons fous, Paint, vous manipulez des formes géométriques déconnectées. Cette flexibilité apparente finit par poser problème. Elle crée de l’incohérence : le “rectangle bleu” d’une équipe n’aura pas forcément la même signification que celui de l’équipe voisine. C’est le retour des heures sombres de Rational Rose, sans la rigueur de l’époque.
La modélisation impose une cohérence. On ne dessine pas un carré, on déclare un composant avec ses propriétés et ses relations. Le principal avantage est la synchronisation.
Dans un modèle, si vous renommez une base de données, le changement se retrouve dans toutes vos vues. Le modèle devient ainsi un langage commun, centralisé et partagé.
Le Modèle C4 : L’art du “Zoom”
Pour structurer cette modélisation sans retomber dans la rigidité de l’UML d’autrefois, le modèle C4 (Software System, Container, Component, Deployment) propose une approche pragmatique. Il organise plusieurs niveaux d’abstraction, chacun correspondant à une perspective :
- Niveau 1 : Software System. La vue d’ensemble. Selon le contexte, ce niveau représente une application, un produit complet ou un service autonome. Il s’adresse notamment aux parties prenantes externes.
- Niveau 2 : Container. On identifie les unités déployables (API, Single Page App, Mobile App, Database). C’est le niveau le plus utile aux nouveaux venus pour comprendre l’écosystème technique.
- Niveau 3 : Component. On entre dans le détail du container : contrôleurs Spring, endpoints et schémas de base de données. Le développeur y documente ses choix d’implémentation.
- Bonus : Deployment View. Souvent oubliée, cette vue relie le Dev et l’Ops. Elle décrit comment les containers sont instanciés sur l’infrastructure réelle (nœuds K8s, pods, clusters). Sans elle, l’architecture reste théorique.
L’Architecture-as-Code (DSL)
Pour rester à jour, l’architecture doit vivre là où travaille le développeur : dans l’IDE. Grâce au Structurizr DSL (sous licence Apache 2.0), l’architecture devient textuelle, versionnable et révisable.
L’approche sépare le modèle (la structure) de la vue (le rendu). Au lieu d’aligner des boîtes, on décrit des relations dans VS Code. Pour travailler au quotidien, des outils comme Structurizr Light (via un container Docker) permettent de prévisualiser localement les modifications. En intégrant le DSL au cycle Git, on peut aussi relire l’architecture avec des Pull Requests et des Code Reviews.
“L’architecture elle n’a de valeur que si elle est compréhensible et accessible. Si elle est gardée au sein d’une équipe, elle a assez peu d’intérêt.”
Interroger son architecture
Une fois modélisée, votre architecture devient une base de données requêtable.
Imaginez une faille de sécurité critique sur MongoDB. Au lieu de parcourir manuellement des dizaines de diagrammes obsolètes, vous posez une question au modèle : “Quels composants consomment MongoDB ?”. L’analyse d’impact devient une tâche rapide et précise. Pour un responsable sécurité, cette visibilité sur les flux et les dépendances facilite l’évaluation des risques.
Automatisation (CI/CD)
L’Architecture-as-Code n’est pas magique. Elle demande de la gouvernance et un “champion” pour porter la démarche. Une fois intégrée à la CI/CD, elle s’insère dans le travail quotidien :
- Commit du DSL : Le développeur met à jour la structure ou ajoute un ADR (Architecture Decision Record) dans le repo Git.
- Pipeline CI/CD : Un workflow (GitHub Actions ou GitLab CI) se déclenche.
- Publication automatisée : Des outils comme Structurizr Site GeneratR produisent un site statique regroupant diagrammes à jour, graphes de navigation et documentation technique.
L’architecture ne reste plus dans un dossier caché. Elle devient accessible et exploitable par tous.
Conclusion
L’Architecture-as-Code ne remplace pas les croquis rapides sur un coin de table. Elle permet de les prolonger avec une documentation durable. En restant proche du quotidien du développeur, elle transforme la documentation en outil d’ingénierie.
Regardez vos schémas actuels : votre architecture est-elle une donnée vivante, précise et requêtable, ou un cimetière numérique de pixels qui risque d’induire votre prochain collègue en erreur ?
Replay en vidéo de ce talk
Si vous préférez le format vidéo, le replay est également disponible sur YouTube: