Styles architecturaux I : monolithes et conceptions modulaires

Bienvenue dans le chapitre 5 : Styles architecturaux, première partie, monolithes et conceptions modulaires. La plupart des logiciels, y compris certains des produits les plus importants et qui connaissent le plus de succès, fonctionnent comme une seule application déployable. Ce chapitre explique comment de telles applications doivent être structurées à l’intérieur, et quand une application unique est la bonne réponse.

Les chapitres 3 et 4 vous ont donné les principes d’une bonne structure, et les outils pour la décrire. Ce chapitre et le suivant transforment ces principes en formes récurrentes que prennent les systèmes réels. Connaître les principaux styles vous permet de partir d’une forme dont on sait qu’elle fonctionne pour un ensemble donné de qualités, de l’expliquer en une phrase et de repérer tôt le moment où un système s’en écarte. Ce chapitre traite des styles où l’application entière est une seule unité de déploiement : un seul build, une seule mise en production, généralement une seule base de données. Cela ne fait pas des monolithes des systèmes primitifs. Qu’un monolithe soit un plaisir ou un calvaire à faire évoluer dépend presque entièrement de la façon dont il est découpé à l’intérieur.

Le chapitre s’adresse aux développeurs et aux architectes qui conçoivent ou maintiennent des applications métier, et qui veulent choisir et faire respecter une structure de façon délibérée. Il s’appuie sur les chapitres 3 et 4, en particulier la modularité, le couplage et la cohésion, les dépendances et l’organisation en couches, et le modèle C4. Les attributs de qualité du chapitre 2 sont utilisés tout au long du chapitre. Et il mène au chapitre 6, qui pose les mêmes questions à travers un réseau, là où les choses se compliquent. Un monolithe évite les pannes réseau, les indisponibilités partielles et les problèmes de cohérence des systèmes distribués. Le chapitre 6 s’y attaque.

D’abord, une définition. Un style architectural est un ensemble nommé de contraintes portant sur les types de parties d’un système, et sur la façon dont elles peuvent se connecter. Les contraintes sont l’essentiel. Interdisez par exemple à un module métier de toucher aux tables d’un autre, et vous obtenez des avantages prévisibles, à un prix prévisible.

Le chapitre compte huit sections. La section cinq point un pose le vocabulaire utilisé pour chaque style des chapitres 5 et 6 : styles, patrons, tactiques et architectures de référence. Elle explique la différence entre le partitionnement technique, par couche, et le partitionnement par domaine, par capacité métier. Et elle présente le quantum d’architecture : une partie déployable indépendamment, données comprises, à laquelle s’applique un seul ensemble de qualités.

Voici pourquoi le partitionnement compte. Supposons qu’une entreprise de livraison de repas permette aux clients d’ajouter un pourboire pour le livreur. Avec un partitionnement technique, ce seul changement touche la couche de présentation, la logique métier et la couche de persistance. Avec un partitionnement par domaine, le même changement se concentre presque entièrement dans le module de livraison, qui peut lui-même rester organisé en couches à l’intérieur. La plupart des demandes de changement métier sont formulées en termes de domaine, si bien que le partitionnement par domaine tend à garder un changement au même endroit. Et il permet à chaque équipe de prendre en charge une capacité métier de bout en bout.

Les sections cinq point deux à cinq point cinq décrivent quatre styles selon le même format, avec un diagramme, un exemple, un tableau des caractéristiques, quand l’utiliser et comment le faire respecter dans le code. L’architecture en couches est l’empilement familier des couches de présentation, métier et persistance. Le monolithe modulaire découpe une application déployable unique par domaine métier, avec des interfaces de modules explicites et une propriété claire des données, illustré par l’expérience de Shopify. Le style tubes et filtres organise le traitement en une chaîne d’étapes indépendantes, des tubes Unix aux pipelines de données. Et le micronoyau construit un noyau minimal que des plug-ins étendent, comme dans les outils de développement, les navigateurs et les moteurs de règles.

Ce diagramme de la section cinq point trois montre l’intérieur d’un monolithe modulaire. La frontière en pointillés est une seule unité de déploiement : l’application de livraison de repas. Chaque module, ici Commandes et Paiements, possède une petite API publique. Commandes ne peut utiliser Paiements qu’en appelant cette API. Tout le reste d’un module est interne. Aller chercher dans les éléments internes d’un autre module depuis ceux d’un module est interdit. Et chaque module possède son propre schéma, sans jointures entre schémas. Respectez ces règles, et n’importe quel module pourra plus tard être extrait en service avec un effort modeste.

La section cinq point six traite des architectures hexagonale, en oignon et Clean Architecture. Elles placent la logique métier au centre, et font dépendre d’elle les bases de données, les interfaces utilisateur et les services externes, jamais l’inverse. La section cinq point sept, sur la conception stratégique pilotée par le domaine, fournit la méthode pour trouver de bonnes frontières : sous-domaines, contextes délimités, et relations entre eux dans une carte de contextes. Enfin, la section cinq point huit se demande quand un monolithe est la bonne réponse, jusqu’où il peut passer à l’échelle, et quels signes indiquent qu’il est temps de le découper. Elle se termine par un guide de décision et un tableau comparatif de tous les styles du chapitre.

Si vous ne deviez retenir qu’une chose, ce serait celle-ci : les frontières à l’intérieur d’un système comptent plus que les frontières entre unités de déploiement. Un ensemble de services qui partagent une base de données et appellent les éléments internes les uns des autres reste un seul système enchevêtré, avec en plus les pannes réseau. Deux habitudes en découlent. D’abord, choisissez le style le plus simple dont les caractéristiques satisfont les exigences architecturalement significatives du système, et consignez ce choix et ses compromis dans un enregistrement de décision. Ensuite, faites respecter les règles du style avec des tests d’architecture dans le build, car tout style s’érode lorsque ses contraintes n’existent que dans la tête des gens.

Lisez d’abord la section cinq point un, car toutes les sections suivantes utilisent son vocabulaire. Ensuite, vous pouvez parcourir les styles dans l’ordre ou piocher dans celui dont vous avez besoin. La lecture du chapitre prend environ trois heures. Suivez la plateforme de livraison de repas tout au long du chapitre. Comparer les styles sur un seul système familier est bien plus facile que sur des exemples jouets sans rapport entre eux. Chaque section se termine par quelques questions d’autoévaluation. Répondez-y de tête avant de regarder. Quand vous êtes prêt, passez le test facultatif du chapitre : vingt questions à choix multiples et deux réponses rédigées, en quarante-cinq minutes environ. La note de réussite est de quatre-vingts pour cent.

Voilà la carte du chapitre 5. Commencez par la section cinq point un, où nous posons le vocabulaire des styles, des patrons et des tactiques sur lequel s’appuient les deux chapitres suivants. À très vite.