Modularité : diviser un système en parties

Ce qu’est un module

Un module est une partie d’un système qui a une responsabilité claire et une manière définie dont les autres parties peuvent l’utiliser. Cette définition est volontairement indépendante de la taille. Dans la section 0.3, un module était un fichier Python ; dans ce chapitre, le mot couvre toute unité de décomposition, c’est-à-dire l’action de diviser un système en parties : une fonction, une classe, un paquet, une bibliothèque, un composant à l’intérieur d’une application, ou un service déployé séparément. Les mêmes questions se posent à toutes les échelles : de quoi cette partie est-elle responsable, qu’offre-t-elle aux autres, que garde-t-elle pour elle, et de quoi dépend-elle ?

Tout module a deux faces. Son interface est ce que les autres modules doivent savoir pour l’utiliser : noms et paramètres des fonctions, une API HTTP, les événements qu’il publie, mais aussi les promesses informelles, comme sa rapidité de réponse et les erreurs qu’il peut renvoyer. Son implémentation est tout le reste : le code, les structures de données, les tables de la base de données, les bibliothèques tierces qu’il se trouve utiliser. Une bonne modularité garde l’interface petite et stable, et laisse l’implémentation changer librement.

David Parnas, dont l’article de 1972 est le fondement de cette section, définissait un module comme une attribution de responsabilité plutôt que comme un morceau de texte de programme. C’est la façon la plus utile d’y penser quand on est architecte. Un module est la promesse qu’une partie du système, et en général une équipe, est responsable d’un ensemble de décisions. Que le code finisse dans un fichier ou dans quarante, dans un processus ou dans dix, est une question distincte, traitée plus bas à propos des modules logiques et physiques.

Pourquoi modulariser

Un système de quelques centaines de lignes peut être compris dans son ensemble. Un système de quelques millions de lignes ne le peut pas, et l’organisation qui le construit ne peut pas non plus travailler comme un seul groupe indivisé. La modularité est la propriété d’être divisé en modules qui peuvent être compris, modifiés et analysés en grande partie isolément. C’est l’une des cinq sous-caractéristiques de la maintenabilité dans ISO/IEC 25010 (section 2.6), et elle procure au moins cinq avantages distincts.

La compréhension. Un développeur peut étudier un module et ses interfaces sans lire le reste du système. Le travail en parallèle. Les équipes peuvent travailler sur des modules différents en même temps avec peu de besoin de coordination, parce qu’elles se sont mises d’accord à l’avance sur les interfaces. L’isolation des changements. Un changement portant sur une décision de conception, par exemple les règles fiscales applicables, est fait dans un seul module et ne se propage pas. La réutilisation. Un module bien délimité, comme un composant de validation d’adresses, peut être utilisé par plusieurs produits. Les tests. Un module doté d’une interface claire peut être testé isolément, ses dépendances étant remplacées par des doublures de test.

Parnas en a cité trois en 1972 : l’avantage managérial (un temps de développement raccourci, parce que des groupes distincts travaillent sur des modules distincts en communiquant peu), la flexibilité (des changements radicaux dans un module sans modifier les autres) et la compréhensibilité (étudier le système un module à la fois). Un demi-siècle plus tard, ce sont toujours les raisons. Mais remarquez qu’aucun de ces avantages ne découle automatiquement du découpage d’un système en morceaux. Un système peut être divisé en cinquante modules et ne procurer aucun de ces avantages si chaque changement en touche dix. Les avantages dépendent entièrement de l’endroit où les frontières sont tracées.

Parnas et l’exemple KWIC

Parnas a illustré son propos avec un petit programme appelé KWIC (key word in context, mot clé dans son contexte), qui produit un index de titres. Il lit des lignes de texte, génère chaque décalage circulaire de chaque ligne (en déplaçant à plusieurs reprises le premier mot à la fin), trie tous les décalages par ordre alphabétique et les imprime. La ligne Design of Software produit Design of Software, of Software Design et Software Design of, de sorte qu’un lecteur peut trouver le titre sous n’importe lequel de ses mots.

La première décomposition qu’il décrit est celle que produiraient la plupart des programmeurs en dessinant un organigramme : un module Entrée qui lit les lignes et les stocke en mémoire dans un format compacté, un module Décalage circulaire qui construit un index indiquant où commence chaque décalage, un module Tri alphabétique qui trie cet index, un module Sortie qui imprime le résultat, et un module de contrôle principal qui les appelle dans l’ordre. C’est une conception parfaitement raisonnable. Chaque module est petit et les interfaces entre eux sont les formats de données en mémoire.

La seconde décomposition paraît plus étrange. Elle comprend un module Stockage des lignes qui offre des fonctions comme donner le caractère de la ligne r, mot w, position c et cache la façon dont les lignes sont réellement stockées ; un module Entrée qui lit les lignes et les confie au Stockage des lignes ; un Décaleur circulaire qui présente les décalages comme s’ils étaient stockés, au moyen de fonctions d’accès similaires ; un Trieur qui offre donne-moi le i-ème décalage dans l’ordre sans dire quand ni comment il trie ; un module Sortie ; et un contrôle principal. Les modules ne correspondent plus aux étapes du traitement.

Parnas a ensuite listé les décisions discutables et susceptibles de changer : le format d’entrée ; le fait de garder toutes les lignes en mémoire, ce qui n’est pas réaliste pour de très grandes entrées ; le fait de compacter plusieurs caractères dans chaque mot machine ; le fait de stocker un index des décalages plutôt que les décalages eux-mêmes ; et le fait de tout trier une fois plutôt que de rechercher à la demande. Dans la première décomposition, la plupart de ces changements touchent plusieurs modules, car chaque module connaît les formats de données partagés. Dans la seconde, chaque changement reste confiné au seul module qui cache la décision correspondante. La seconde conception était aussi plus facile à développer en parallèle, parce que les équipes n’avaient à s’accorder que sur des noms de fonctions et des paramètres, et non sur des structures de tables détaillées, et plus facile à comprendre un module à la fois.

Le critère : décomposer selon les décisions susceptibles de changer

Parnas concluait qu’il est presque toujours incorrect de commencer à décomposer un système à partir d’un organigramme. Il proposait plutôt de partir d’une liste de décisions de conception difficiles, ou de décisions de conception susceptibles de changer, et de concevoir chaque module pour qu’il cache l’une de ces décisions aux autres. Il a appelé ce principe le masquage de l’information (information hiding) ; la section 3.3 le traite en profondeur.

L’idée paraît simple, mais elle va à l’encontre de l’instinct de la plupart d’entre nous. Un organigramme décrit le temps : d’abord ceci, ensuite cela. Les décisions de conception traversent le temps. La décision sur la façon de représenter une commande sert quand la commande est reçue, tarifée, payée, enregistrée et confirmée. Si les modules suivent les étapes, cette décision unique est répartie entre toutes, et la changer impose de toutes les changer. Si un module possède la décision, toutes les étapes s’adressent à ce module, et la décision peut changer en un seul endroit.

Deux précisions comptent en pratique. D’abord, le critère porte sur les changements probables, ce qui signifie qu’un architecte doit faire une supposition éclairée sur l’avenir : ce qui a changé dans des systèmes similaires, ce que l’entreprise prévoit, quels fournisseurs et quelles réglementations sont instables. Les quatre questions de modifiabilité de la section 2.6 (qu’est-ce qui change, avec quelle probabilité, qui le change, à quel coût) sont exactement les données d’entrée dont il a besoin. Ensuite, Parnas distinguait une bonne décomposition d’une hiérarchie. Un système peut être proprement organisé en couches et pourtant mal décomposé, et inversement ; la section 3.4 traite séparément du sens des dépendances.

Modules logiques et modules physiques

Un module logique est une unité de responsabilité dans la conception : Catalogue, Commandes, Paiements. Un module physique est une unité que l’on construit, que l’on versionne ou que l’on déploie : un fichier JAR Java, un wheel Python, un paquet npm, une image de conteneur, une fonction serverless. La section 1.1 les a appelées structures de modules et structures d’allocation. Les deux sont liées, mais ce n’est pas la même chose, et les confondre est à l’origine de certaines des erreurs les plus coûteuses de l’architecture moderne.

Une même conception logique peut être projetée sur des modules physiques de façons très différentes. Tous les modules logiques peuvent vivre dans une seule unité déployable et s’appeler les uns les autres au sein du même processus : c’est un monolithe modulaire. Ou bien chacun peut être déployé comme un service à part, qui appelle les autres par le réseau : ce sont des microservices. Les frontières logiques, et les décisions que cache chaque module, peuvent être identiques dans les deux cas. Ce qui change, c’est le coût du franchissement d’une frontière (un appel de fonction prend des nanosecondes, un appel réseau des millisecondes, et il peut échouer), la possibilité de mettre en production et de faire passer à l’échelle des parties de façon indépendante, et le travail d’exploitation.

Une erreur courante et coûteuse consiste à traiter la séparation physique comme si elle créait la modularité logique. Découper en services un système mal décomposé ne cache aucune décision ; cela transforme des appels internes entre modules enchevêtrés en appels réseau entre services enchevêtrés, ce que l’on appelle parfois un monolithe distribué. L’erreur inverse existe aussi : une équipe garde une seule unité déployable mais laisse ses modules internes s’imbriquer les uns dans les autres, si bien qu’elle ne pourra jamais les séparer par la suite. Le conseil pratique de nombreux praticiens est de commencer par bien définir les frontières logiques, de les faire respecter, et seulement ensuite de décider lesquelles méritent de devenir des frontières physiques.

La granularité et ses coûts

Quelle taille doit avoir un module ? La granularité est la taille des modules par rapport au système, et il n’existe pas de bonne réponse universelle, car les coûts tirent dans des directions opposées. Les modules plus grands ont moins d’interfaces à concevoir et à maintenir, mais chacun contient davantage de raisons de changer sans rapport entre elles, davantage de personnes qui le modifient en même temps, et davantage de choses à comprendre avant de faire un changement. Les modules plus petits sont chacun plus faciles à comprendre, mais le système a plus d’interfaces, plus de dépendances à gérer et plus d’endroits où une même fonctionnalité doit être assemblée morceau par morceau.

Le coût d’une interface dépend aussi du type de frontière. Entre deux classes d’un même programme, une interface supplémentaire coûte un peu de temps de lecture. Entre deux services, elle coûte un saut réseau, de la sérialisation, une politique de versionnage, de la supervision, un mode de défaillance et peut-être l’accord d’une seconde équipe pour chaque changement. C’est pourquoi la bonne granularité pour les services est généralement bien plus grossière que la bonne granularité pour les classes.

Faire respecter les frontières des modules dans le code

Une frontière qui n’existe que sur un schéma ne survivra pas à l’épreuve d’une échéance. Tôt ou tard, quelqu’un importera une classe interne parce que c’est plus rapide, et dès qu’un raccourci existe, d’autres suivent ; la section 1.7 a appelé cela l’érosion. Les langages et les outils de build offrent plusieurs moyens de faire de la frontière voulue le chemin de moindre résistance, ou de faire échouer le build quand on la franchit.

Python repose sur des conventions : les noms qui commencent par un tiret bas sont considérés comme internes (PEP 8), et le fichier __init__.py d’un paquet peut ne réexporter que ses fonctions publiques. Rien n’empêche d’importer shop.payments._stripe_client : les équipes soucieuses de leurs frontières utilisent donc un vérificateur comme import-linter pour faire échouer le build quand un import interdit apparaît. Java offre la visibilité package-private (la visibilité par défaut quand aucun modificateur n’est indiqué) et, depuis Java 9 en 2017, le Java Platform Module System : un fichier module-info.java déclare de quels modules celui-ci a besoin (requires) et lesquels de ses paquets il exporte (exports) ; les paquets qui ne sont pas exportés ne peuvent pas être utilisés de l’extérieur, ni à la compilation ni à l’exécution. Go considère tout paquet situé sous un répertoire nommé internal comme importable uniquement depuis le code enraciné dans le parent de ce répertoire. C# dispose de internal, visible uniquement au sein d’un assembly ; Rust, de pub(crate).

# shop/payments/__init__.py  (the public face of the package)
from shop.payments.api import charge, refund, PaymentResult

__all__ = ["charge", "refund", "PaymentResult"]

# shop/payments/_provider_client.py   internal: leading underscore
# shop/payments/_retry.py             internal
# shop/payments/api.py                the only module callers should use

# Elsewhere in the shop:
from shop.payments import charge          # fine
from shop.payments._retry import backoff  # works, but breaks the boundary

// module-info.java for the payments module
module shop.payments {
    requires shop.orders.api;        // what this module depends on
    exports shop.payments.api;       // the only package others can use
    // shop.payments.provider and shop.payments.retry are not exported,
    // so code in other modules cannot compile against them
}

Erreurs courantes

Décomposer uniquement par couche technique. Des dossiers appelés controllers, services et repositories sont des modules d’une certaine sorte, mais un changement dans le fonctionnement de la TVA touchera les trois. Les couches sont utiles (section 3.4), mais une décomposition qui n’a que des couches est un organigramme déguisé. La plupart des systèmes matures combinent un découpage par capacité métier et une organisation en couches à l’intérieur de chaque partie.

Tout partager. Un module appelé common ou utils que tous les autres modules importent devient l’endroit où s’accumulent des décisions sans rapport entre elles, et tout changement qui le touche se propage partout. Des frontières sans contrôle. Les schémas montrent des modules propres alors que le code contient des centaines d’imports croisés. Des modules définis par l’organigramme d’une réorganisation passée plutôt que par les décisions que le système doit cacher ; la section 3.7 explique pourquoi les organisations et les frontières des modules s’influencent mutuellement. La distribution prématurée. Transformer chaque module logique en service avant que les frontières aient prouvé leur stabilité rend coûteuses les corrections ultérieures de frontières.

Comment les professionnels appliquent la modularité

Les architectes expérimentés considèrent la structure des modules comme l’artefact de conception le plus important pour la maintenabilité, et ils y reviennent régulièrement. Au début de la vie d’un produit, quand le domaine est mal compris, ils préfèrent des modules moins nombreux et plus grands, avec de solides frontières internes, parce que fusionner et scinder des modules au sein d’une même base de code coûte peu. À mesure que le domaine se stabilise et que les changements probables deviennent clairs, ils affinent les frontières et ce n’est qu’alors qu’ils se demandent lesquelles devraient être déployées séparément. Les techniques de la conception pilotée par le domaine, comme les contextes délimités (bounded contexts), aident à trouver des frontières qui suivent le langage du métier.

Ils mesurent aussi. Compter les modules touchés par les changements récents, ce que l’historique de la gestion de versions rend facile, montre si les frontières fonctionnent ; la section 3.8 présente le couplage de changement et les hotspots (points chauds). La section suivante, la section 3.2, donne le vocabulaire pour décrire à quoi ressemblent de bonnes et de mauvaises frontières : le couplage entre modules et la cohésion à l’intérieur de chacun.