Styles architecturaux, patrons et tactiques

Pourquoi les architectes nomment des formes

La plupart des systèmes ne sont pas conçus à partir de rien. Les architectes expérimentés reconnaissent qu’un nouveau problème ressemble à un problème déjà rencontré et se tournent vers une forme dont on sait qu’elle fonctionne : quelques couches pour une application métier simple, une chaîne d’étapes de traitement pour un flux de données, un noyau avec des plug-ins pour un produit que les clients étendent. Nommer ces formes donne à une équipe un vocabulaire commun. Dire c’est un monolithe modulaire avec une communication par événements entre les modules transmet en une phrase ce qui demanderait sinon une page de diagrammes, et cela apporte avec soi tout un savoir sur ce qui tend à bien ou mal se passer.

David Garlan et Mary Shaw ont donné une base solide à cette démarche dans An Introduction to Software Architecture (rapport technique de Carnegie Mellon, 1994) et dans leur livre Software Architecture: Perspectives on an Emerging Discipline (1996). Ils ont décrit un style architectural comme un vocabulaire de types de composants et de connecteurs, accompagné d’un ensemble de contraintes sur la façon dont ils peuvent être combinés. Le style tubes et filtres, par exemple, a une seule sorte de composant (un filtre qui transforme des données) et une seule sorte de connecteur (un tube qui les transporte dans un seul sens), et il impose aux filtres de ne pas partager d’état et de ne pas savoir qui sont leurs voisins. Roy Fielding, dont la thèse (2000) a défini REST comme un style, a formulé la même idée plus nettement : un style est un ensemble coordonné de contraintes, et ce sont les contraintes qui produisent les propriétés. Interdisez aux filtres de partager un état et vous obtenez des filtres qui peuvent être testés, réutilisés et réarrangés indépendamment ; ce n’est pas de la chance, c’est une conséquence de la règle.

C’est la façon la plus utile de lire chaque style de ce chapitre et du suivant. Un style n’est pas une image à copier. C’est un ensemble de règles que vous acceptez de suivre, choisies parce que les suivre procure des caractéristiques d’architecture précises, les attributs de qualité du chapitre 2, moyennant un prix. Une équipe qui adopte le vocabulaire d’un style mais pas ses règles paie le prix sans obtenir les avantages.

Styles, patrons, tactiques et architectures de référence

Quatre termes apparentés sont utilisés, souvent de façon approximative, pour désigner un savoir de conception réutilisable. Ils diffèrent surtout par leur portée et par leur degré de prescription.

Un patron architectural décrit une solution éprouvée à un problème structurel récurrent dans un contexte donné. L’idée de patron vient de l’architecte du bâtiment Christopher Alexander et est entrée dans le logiciel avec les patrons de conception de Gamma, Helm, Johnson et Vlissides (1994), qui opèrent à l’échelle de quelques classes. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, de Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad et Michael Stal (1996), qu’on appelle généralement POSA, a catalogué des patrons à l’échelle de systèmes entiers : Couches (Layers), Tubes et filtres (Pipes and Filters) et Tableau noir (Blackboard) (regroupés sous le thème « de la boue à la structure »), Courtier (Broker) pour les systèmes distribués, Modèle-Vue-Contrôleur et Présentation-Abstraction-Contrôle pour les systèmes interactifs, et Micronoyau (Microkernel) et Réflexion (Reflection) pour les systèmes adaptables. Chaque patron de POSA est rédigé sous la forme contexte, problème, forces et solution, avec ses conséquences, ce qui rend les compromis explicites.

Une tactique, au sens où l’entendent Len Bass, Paul Clements et Rick Kazman dans Software Architecture in Practice, est plus petite : une seule décision de conception qui influe sur une réponse d’un attribut de qualité, comme ajouter un heartbeat pour détecter un serveur défaillant ou un cache pour réduire la latence. La section 2.6 a utilisé des tactiques de modifiabilité comme l’encapsulation et le recours à un intermédiaire. Les patrons regroupent plusieurs tactiques : le patron Couches combine l’encapsulation, la restriction des dépendances et le recours à un intermédiaire.

Une architecture de référence est un modèle pour tout un domaine ou toute une plateforme : elle nomme les blocs de construction typiques et la façon dont ils se connectent, afin que les projets l’adaptent plutôt que de partir d’une page blanche. AUTOSAR, l’architecture logicielle en couches utilisée pour les calculateurs électroniques des voitures, en est un exemple bien connu ; les centres d’architecture publiés par les fournisseurs de cloud en offrent beaucoup de plus petites. Une architecture de référence est généralement construite à partir de plusieurs styles et patrons à la fois.

Les praticiens ne s’accordent pas sur l’endroit où passe la frontière entre style et patron. POSA appelle Couches un patron ; Garlan et Shaw appellent les systèmes en couches un style ; Mark Richards et Neal Ford, dans Fundamentals of Software Architecture, réservent le mot style à la topologie globale d’un système et le mot patron aux structures réutilisables de plus bas niveau qui peuvent apparaître à l’intérieur de nombreux styles. Ce cours suit l’usage courant : style pour la forme globale d’un système ou d’une grande partie de celui-ci, patron pour une solution réutilisable qui peut se situer à n’importe quel niveau. Ne dépensez pas d’énergie sur la frontière ; consacrez-la aux contraintes et à leurs conséquences.

Deux façons de découper un système : partitionnement technique ou par domaine

La première décision structurelle de tout style est la façon de découper le système au niveau supérieur. Il existe deux réponses de base. Le partitionnement technique regroupe le code selon le rôle technique : tout ce qui concerne l’interface utilisateur à un endroit, toutes les règles métier à un autre, tout l’accès à la base de données à un troisième. Le partitionnement par domaine regroupe le code par capacité métier : tout ce qui concerne les commandes à un endroit, les paiements à un autre, la livraison à un troisième, chacun contenant l’interface utilisateur, la logique et l’accès aux données dont il a besoin.

La différence apparaît dès qu’une fonctionnalité change. Supposons qu’une entreprise de livraison de repas permette aux clients d’ajouter un pourboire pour le livreur. Dans un système partitionné techniquement, ce changement demande un nouveau champ sur un écran (présentation), une nouvelle règle pour les plafonds de pourboire et les versements (logique métier) ainsi qu’une nouvelle colonne et une nouvelle requête (persistance) : trois parties, souvent prises en charge par trois personnes ou équipes différentes. Dans un système partitionné par domaine, le même changement se concentre presque entièrement dans le module de livraison. 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. Le partitionnement technique garde au même endroit un changement technique, comme le remplacement de la bibliothèque d’accès à la base de données, mais ces changements sont plus rares.

Ce choix façonne aussi l’organisation. Selon la loi de Conway, un système partitionné techniquement tend à être construit par une équipe frontend, une équipe backend et une équipe base de données, et chaque fonctionnalité exige un passage de relais entre elles. Un système partitionné par domaine peut être construit par des équipes qui prennent chacune en charge une capacité métier de bout en bout. Martin Fowler a formulé la même recommandation en 2015 : les couches présentation, domaine et données sont une bonne façon d’organiser un petit logiciel, mais le niveau supérieur d’un système plus grand doit être découpé en modules orientés domaine, chacun organisé en couches à l’intérieur si cela aide.

Aucune des deux n’est mauvaise. Le partitionnement technique est simple, familier et pris en charge par la structure de dossiers par défaut de presque tous les frameworks web, et il convient aux petits systèmes où une seule équipe fait tout. Le partitionnement par domaine demande davantage de réflexion en amont, car il faut trouver de bonnes frontières de domaine (le sujet de la section 5.7), mais il s’adapte mieux à la taille du système et au nombre d’équipes.

Styles monolithiques et distribués

La seconde distinction de premier niveau concerne le déploiement. Une unité de déploiement est ce qui est construit, mis en production et démarré d’un seul tenant : un exécutable unique, une image de conteneur, une archive web. Dans une architecture monolithique, l’application entière est une seule unité de déploiement, généralement avec une seule base de données. Elle peut tourner en de nombreuses copies identiques derrière un équilibreur de charge, mais chaque copie contient tout le code, et mettre en production le moindre changement signifie tout mettre en production. Dans une architecture distribuée, le système se compose de plusieurs unités de déploiement qui coopèrent en échangeant des messages à travers un réseau, et chacune peut être mise en production et passer à l’échelle séparément.

Deux précisions évitent bien des confusions. D’abord, monolithe décrit le déploiement, pas la qualité. Un monolithe peut être magnifiquement modulaire ou être une grosse boule de boue (le nom donné par Brian Foote et Joseph Yoder à un système sans structure discernable), et il en va de même d’un système distribué : bien des équipes ont appris que découper une boule de boue en services donne une boule de boue distribuée, ce qui est pire. Ensuite, être distribué n’est pas une amélioration gratuite. Chaque appel qui traverse un réseau peut être lent, échouer à mi-chemin ou arriver deux fois, les données ne peuvent plus être modifiées dans une seule transaction locale, et le système exige une supervision, une automatisation du déploiement et des compétences d’astreinte dont un monolithe peut se passer. Le chapitre 6 détaille ces coûts. Ce chapitre traite des styles qui les évitent : tout tourne dans une seule unité de déploiement, et l’architecture réside dans la façon dont le code y est organisé.

Le quantum d’architecture

L’opposition entre monolithique et distribué est un premier découpage utile, mais trop grossier pour les décisions réelles. Neal Ford, Rebecca Parsons et Patrick Kua ont introduit une idée plus précise dans Building Evolutionary Architectures (2017), affinée par Ford, Richards, Sadalage et Dehghani dans Software Architecture: The Hard Parts (2021) : le quantum d’architecture. Un quantum est une partie du système qui peut être déployée indépendamment, qui présente une forte cohésion fonctionnelle (elle accomplit une seule tâche cohérente pour le métier) et qui inclut tout ce dont elle a besoin pour fonctionner, en particulier sa base de données. La définition ultérieure ajoute que les parties d’un quantum sont couplées statiquement (elles partagent du code, des schémas ou une infrastructure qui doivent être déployés ensemble) et que les appels synchrones lient les quanta entre eux sur le plan opérationnel tant que dure l’appel.

Pourquoi est-ce important ? Parce que les caractéristiques d’architecture s’appliquent par quantum. Un quantum passe à l’échelle, est déployé, sécurisé et rétabli comme un tout : il a donc un seul niveau de scalabilité, un seul niveau de disponibilité, une seule cadence de mise en production. Si deux parties d’un système ont besoin de caractéristiques très différentes, par exemple un flux de positions des livreurs qui doit absorber des milliers de mises à jour par seconde et une tâche mensuelle de facturation des restaurants, elles ne peuvent les obtenir qu’en se trouvant dans des quanta différents. À l’inverse, découper du code en plusieurs services ne crée pas plusieurs quanta s’ils partagent toujours une seule base de données : aucun d’eux ne peut changer le schéma ni être restauré seul, si bien qu’ils tiennent ou tombent ensemble. Un monolithe est, par définition, un seul quantum.

Comment lire les sections de styles qui suivent

Les sections 5.2 à 5.5 et la majeure partie du chapitre 6 décrivent chacune un style, toujours dans le même ordre, afin que les styles puissent être comparés : une définition et l’origine du style ; un diagramme ; son fonctionnement ; un exemple concret de système ; un tableau qui évalue ses principales caractéristiques ; quand l’utiliser et quand l’éviter ; les anti-patrons courants ; et la manière de le faire respecter dans le code, car un style qui n’est pas vérifié s’érode, comme l’a décrit la section 1.7.

Les évaluations des caractéristiques (Bas, Moyen, Élevé, chacune avec une justification) suivent l’approche des comparaisons de styles de Richards et Ford, mais ce sont les jugements propres à ce cours. Lisez-les comme relatives et typiques : elles comparent les styles tels qu’ils sont habituellement construits, par une équipe compétente, pour un système métier typique. Une équipe disciplinée peut réaliser un monolithe en couches qui se déploie plusieurs fois par jour, et une équipe négligente peut construire des microservices impossibles à déployer. Les évaluations vous indiquent où le style vous aide et où vous devrez lutter contre lui.

Deux sections de ce chapitre ne portent pas sur des styles de déploiement. Les architectures hexagonale, en oignon et Clean Architecture (section 5.6) décrivent comment organiser l’intérieur d’une application ou d’un service pour que la logique métier ne dépende pas de la technologie. La conception pilotée par le domaine (section 5.7) est une façon de trouver les frontières de domaine sur lesquelles s’appuient les monolithes modulaires et les microservices. Les deux s’appliquent aussi bien à l’intérieur d’un monolithe que d’un système distribué.

Les styles se combinent, et ce ne sont pas des objectifs

Les systèmes réels sont hybrides. Un monolithe modulaire peut être organisé en couches à l’intérieur de chaque module ; l’un de ses modules peut exécuter une tâche nocturne en tubes et filtres ; un microservice peut être construit en style hexagonal ; un système piloté par les événements peut utiliser un micronoyau pour permettre aux clients d’ajouter leurs propres règles. Nommer le style de chaque partie reste utile, car chaque partie hérite alors d’un ensemble connu de règles et de compromis.

L’erreur courante consiste à traiter un style comme une fin en soi : nous passons aux microservices comme stratégie, plutôt que comme moyen d’atteindre une qualité énoncée, par exemple le déploiement indépendant pour douze équipes. Partez des exigences architecturalement significatives du chapitre 2, choisissez le style le plus simple dont les caractéristiques les satisfont, consignez ce choix dans un enregistrement de décision et faites respecter ses règles. La section 5.8 propose un guide de décision pour les styles de ce chapitre.