Architecture
Concevoir l’architecture d’un logiciel, c’est prendre les décisions qui seront coûteuses à défaire. Le reste — le nom d’une variable, le choix d’une bibliothèque de formatage de dates — se corrige en une après-midi et ne mérite pas ce nom.
Cette section les traite par échelle croissante, parce que c’est l’axe qui détermine tout le reste. Une décision sur une classe, une sur une application et une sur un système ne se prennent ni avec les mêmes critères, ni par les mêmes personnes, ni au même moment — et confondre les échelles est la source d’à peu près tous les débats stériles sur le sujet.
Un fil traverse les quatre groupes : le métier est la partie stable et précieuse, la technique est la partie volatile, et presque toute décision d’architecture revient à empêcher la seconde de contaminer la première.
Le vocabulaire d’abord
Plusieurs mots employés ici ont deux ou trois sens — domaine, entité, service en particulier — et les confusions qui en résultent ne sont pas innocentes : elles conduisent à de mauvaises décisions de conception.
- Les mots ambigus séparés sens par sens, puis tout le vocabulaire de la section groupé par thème. À ouvrir dès qu’un terme accroche.
À l’échelle de la classe et du module
Où placer une responsabilité, et comment reconnaître qu’elle est mal placée.
- Les cinq principes, ce qu’ils coûtent quand on les sur-applique, et l’inversion des dépendances dont tout le reste de la section découle.
- Les 23 patrons du Gang of Four, classés par fréquence d’usage réelle — et ce que les langages modernes ont rendu inutile.
- L’instrument qui manque aux deux pages précédentes : comment juger qu’une dépendance est acceptable, et où placer une frontière plutôt qu’une autre.
À l’échelle de l’application
Comment ranger un programme entier, et à partir de quand chaque forme devient un handicap.
- Le 3-tier — contrôleur, service, dépôt. Pourquoi il domine, pour quelles applications il reste le bon choix, et les sept signaux de saturation.
- Ports et adaptateurs : la règle de dépendance, les organisations de fichiers possibles, ce que ça coûte, et pour quels projets c’est du sur-travail.
À l’échelle du système
Découper un métier, décider des frontières, et faire communiquer les morceaux.
- Dix pages : le volet stratégique — langage, sous-domaines, contextes délimités, cartographie — puis le tactique — entités, agrégats, événements — et la pratique.
- La décision de déploiement, distincte de celle de modélisation : ce que le réseau coûte, les trois seules raisons de le payer, et pourquoi le monolithe modulaire est le bon défaut.
- Deux décisions indépendantes, aux coûts opposés : séparer lecture et écriture — ce qu’il faut presque toujours faire — et stocker les faits plutôt que l’état — ce qu’il faut rarement faire.
- Le pendant du catalogue GoF à l’échelle distribuée : délais d’attente, reprises, disjoncteurs, cloisonnement — et pourquoi la panne se propage par les ressources bloquées, pas par les erreurs.
Documenter, décider, vérifier
Ce qui reste quand l’équipe change : ce qui mérite d’être écrit, la structure, les raisons, et les garde-fous.
- Ce qui vient avant le choix d’un outil : classer par vitesse de péremption, les quatre formes de Diátaxis, le squelette arc42, et l’architecture-as-code comme principe.
- Quatre niveaux de zoom pour des diagrammes lisibles, et Structurizr pour décrire un modèle unique plutôt que dessiner des images qui divergent.
- Trois diagrammes sur quatorze valent d’être connus — séquence, états, classes. Et la notation des relations, que tout le monde utilise de travers.
- Un fichier par décision d’architecture. Ce que C4 ne dit pas : pourquoi la structure est ainsi.
- Rendre exécutables les règles posées par toute la section : une frontière qui n’échoue pas en CI est une convention, pas une frontière.
Comment lire
Les trois premiers groupes se lisent dans l’ordre : chacun suppose le précédent, et plusieurs pages s’appuient explicitement sur celles d’avant — le DDD tactique présuppose de savoir où vit le domaine, ce qui est le sujet de l’hexagone. Le quatrième est transverse et se lit à n’importe quel moment.
Chaque page est cependant autonome et se termine par ses propres références. Le plus souvent, on n’arrive pas ici pour lire dans l’ordre mais avec un problème :
| Le symptôme | Où aller |
|---|---|
| « Notre code devient difficile à modifier » | SOLID, puis Couplage et connascence |
| « On ne sait plus de quoi on parle » | Langage omniprésent, Contextes délimités |
| « Impossible de tester une règle sans base de données » | Les sept signaux du 3-tier, puis Hexagonal |
| « Nos services ont des méthodes de mille lignes » | Agrégats et Services, dépôts, fabriques |
| « Le dépôt a quarante méthodes, les écrans sont lents » | CQRS degré 1 |
| « Faut-il passer aux microservices ? » | Monolithe, modulaire, microservices |
| « Une panne d’un service en entraîne d’autres » | Patrons de résilience |
| « Notre documentation est fausse, ou personne ne la lit » | Documenter une architecture |
| « Personne ne sait pourquoi c’est comme ça » | ADR, puis C4 |
| « Nos règles d’architecture ne sont pas respectées » | Tests d’architecture |