Gérer les dépendances : sens, cycles et stabilité

Pourquoi le sens compte

Une dépendance existe quand un module a besoin d’un autre pour compiler, s’exécuter ou se comporter correctement. Représentez-la par une flèche qui va du module qui dépend vers le module dont il dépend : de Paiement vers Tarification. La flèche vous apprend quelque chose d’important sur le changement. Si Tarification change d’interface ou de comportement, Paiement devra peut-être changer ; si Paiement change, Tarification n’en a cure. Les changements se propagent à contre-sens des flèches. Le sens de chaque dépendance est donc une décision sur qui sera dérangé par les changements de qui.

Les architectes s’intéressent à deux sortes de sens faciles à confondre. Le flot de contrôle indique qui appelle qui à l’exécution. La dépendance de code source indique qui importe, référence ou compile contre qui. En général, les deux pointent dans le même sens, mais ce n’est pas obligatoire. Un framework appelle votre code sans en dépendre (la section 0.3 a appelé cela l’inversion de contrôle), et grâce à une interface, un module de haut niveau peut appeler un module de bas niveau alors que la dépendance de code source pointe dans l’autre sens. Cette liberté de choisir le sens de la dépendance de code source indépendamment du flot de contrôle est l’outil le plus puissant de cette section.

Entre services, le sens se manifeste sous forme de connaissance. Si Commandes appelle l’API de Facturation, Commandes dépend de Facturation et doit changer quand l’API de Facturation change. Si Commandes publie un événement que Facturation consomme, la dépendance s’inverse : Facturation dépend du contrat d’événement de Commandes, et Commandes ne sait même pas que Facturation existe (section 3.2). Choisir entre un appel et un événement, c’est donc en partie choisir le sens d’une dépendance.

Le principe des dépendances acycliques

Robert C. Martin a formulé trois principes pour les dépendances entre composants, d’abord dans des articles au milieu des années 1990, puis dans Agile Software Development: Principles, Patterns, and Practices (2002) et Clean Architecture (2017). Le premier, le principe des dépendances acycliques (ADP), dit que le graphe des dépendances entre composants ne doit contenir aucun cycle : ce doit être un graphe orienté acyclique.

Un cycle de dépendances, par exemple Commandes dépend de Notifications, Notifications dépend de Clients et Clients dépend de Commandes, transforme trois composants en un seul. Aucun ne peut être compilé ou testé sans les autres ; un changement dans l’un peut faire le tour de la boucle et revenir jusqu’à lui ; aucun ne peut être mis en production seul ; et personne ne peut dire lequel construire en premier. Martin introduit le principe avec ce qu’il appelle le syndrome du lendemain matin : vous rentrez chez vous avec du code qui fonctionne et revenez le lendemain pour le trouver cassé, parce que quelqu’un d’autre a modifié quelque chose dont vous dépendez. Son remède consiste à découper le système en composants mis en production séparément, et cela ne fonctionne que si les dépendances entre eux ne contiennent aucun cycle. Les cycles empêchent aussi d’extraire plus tard un composant sous forme de bibliothèque ou de service, car il entraîne toute la boucle avec lui.

Le Java Platform Module System impose l’ADP entre modules : la Java Language Specification fait une erreur de compilation du fait qu’un module dépende, directement ou indirectement, de lui-même. La plupart des autres langages autorisent les cycles entre paquets ; les équipes les détectent donc avec des outils. Les cycles entre classes à l’intérieur d’un petit composant sont moins nuisibles, et Martin Fowler, entre autres, les y tolère ; le principe compte surtout entre des composants que des personnes différentes construisent et mettent en production.

Casser les cycles

Tout cycle peut être cassé, et il existe deux techniques classiques. Le schéma ci-dessous les montre toutes deux pour un cycle dans lequel Commandes appelle Notifications pour envoyer une confirmation, et Notifications rappelle Commandes pour lire les détails de la commande.

Inversion des dépendances. Notifications déclare une interface qui décrit exactement ce dont il a besoin, par exemple OrderLookup avec une seule méthode, et Commandes l’implémente. La flèche de Notifications vers Commandes pointe maintenant dans l’autre sens : Commandes dépend de Notifications (pour l’appeler et pour implémenter son interface), et Notifications ne dépend de rien dans Commandes. C’est l’inversion des dépendances, que la section 3.5 traite comme le D de SOLID. Le détail clé est la propriété : l’interface appartient au module qui l’utilise, et non à celui qui l’implémente.

Extraire un nouveau composant. Repérez ce dont les deux côtés ont réellement besoin l’un de l’autre, souvent un petit modèle ou un contrat commun, et placez-le dans un nouveau composant dont les deux dépendent. Ici, Commandes publie un type d’événement défini dans un composant événements de commande, et Notifications lit les détails de la commande dans l’événement au lieu de rappeler Commandes. Le nouveau composant est utilisé par les deux et ne dépend d’aucun, si bien qu’il est plus stable que chacun d’eux : c’est exactement ce que demande le principe suivant.

Le principe des dépendances stables et l’instabilité

Certains composants changent souvent (interfaces utilisateur, intégrations avec des partenaires, nouvelles fonctionnalités) ; d’autres devraient changer rarement (concepts centraux du domaine, contrats partagés, gestion de l’argent). Le principe des dépendances stables (SDP) dit : dépendez dans le sens de la stabilité. Un composant censé être facile à changer ne devrait pas être utilisé par un composant difficile à changer, sinon il deviendra lui aussi difficile à changer.

Martin mesure la stabilité par les dépendances, et non par la fréquence à laquelle le code est modifié. Un composant dont beaucoup d’autres dépendent est stable, au sens où il est coûteux à changer : chaque changement risque de casser ce qui dépend de lui. Un composant qui dépend de beaucoup d’autres et dont rien ne dépend est instable : rien ne l’empêche de changer, et ses dépendances peuvent l’y obliger. À partir du couplage afférent (Ca, entrant) et du couplage efférent (Ce, sortant) de la section 3.2, l’instabilité vaut :

I = Ce / (Ca + Ce)

I va de 0 à 1. I = 0 signifie uniquement des dépendances entrantes : stabilité maximale, des responsabilités envers beaucoup, aucune dépendance. I = 1 signifie uniquement des dépendances sortantes : instabilité maximale, rien ne dépend de lui. Exprimé sous forme de métrique, le SDP dit que I doit diminuer le long de chaque flèche de dépendance : chaque composant doit dépendre de composants dont le I est plus faible que le sien. Une dépendance d’un composant stable (I = 0,1) vers un composant volatil (I = 0,8) est un signal d’alerte ; le remède habituel est là encore l’inversion des dépendances, en plaçant une interface à un endroit stable.

Le principe des abstractions stables et la séquence principale

La stabilité a un coût : un composant dont le I est proche de 0 est difficile à changer. S’il est rempli de code concret, le système devient rigide. Le principe des abstractions stables (SAP) résout ce problème : un composant doit être aussi abstrait qu’il est stable. Les composants stables doivent se composer surtout d’interfaces et de types abstraits, pour que leur comportement puisse être étendu par de nouvelles implémentations ailleurs sans les modifier ; les composants instables peuvent être concrets, car ils sont de toute façon faciles à changer. Ensemble, le SDP et le SAP reviennent au principe d’inversion des dépendances appliqué à des composants entiers : les dépendances pointent vers la stabilité, et la stabilité va de pair avec l’abstraction.

Le degré d’abstraction se mesure par A = Na / Nc, où Na est le nombre de classes abstraites et d’interfaces du composant et Nc le nombre total de classes. A = 0 signifie entièrement concret ; A = 1 signifie uniquement des abstractions. Reporter A en fonction de I donne un carré. La droite qui va de (I = 0, A = 1) à (I = 1, A = 0) est la séquence principale (main sequence) : stable et abstrait à une extrémité, instable et concret à l’autre, avec des mélanges équilibrés entre les deux. La distance à cette droite vaut :

D = |A + I - 1|

D va de 0 (sur la droite) à 1 (dans un coin éloigné). Le coin proche de (0, 0) est la zone de douleur : stable, parce que beaucoup de choses en dépendent, et concret, si bien que tout changement est à la fois nécessaire et douloureux. Un schéma de base de données que chaque module lit directement se trouve là. Martin note que certains composants y ont leur place sans dommage, comme une bibliothèque utilitaire concrète et mature qui n’a jamais besoin de changer ; la zone ne fait mal que pour les composants volatils. Le coin proche de (1, 1) est la zone d’inutilité : des abstractions dont rien ne dépend, typiquement des interfaces laissées à l’abandon après un refactoring ou conçues pour une extension qui n’est jamais venue.

Organisation en couches stricte et souple

L’organisation en couches (layering) est la règle de dépendance la plus ancienne et la plus courante : disposer les modules en couches, comme la présentation, l’application ou le domaine, et la persistance, et n’autoriser chaque couche à utiliser que les couches situées en dessous. Les couches inférieures ne savent rien des couches supérieures, si bien qu’on peut ajouter une nouvelle interface utilisateur sans modifier le domaine. L’organisation en couches est un style architectural à part entière (section 5.2) ; ici, ce qui nous intéresse est la règle de dépendance qu’elle impose.

Dans l’organisation en couches stricte (fermée), chaque couche ne peut utiliser que la couche immédiatement inférieure. Chaque couche cache alors tout ce qui se trouve en dessous d’elle, et remplacer une couche inférieure n’affecte qu’une seule autre couche ; le prix à payer est du code de simple transmission, où la couche intermédiaire se contente de relayer des appels auxquels elle n’a rien à ajouter. Dans l’organisation en couches souple (ouverte), une couche peut utiliser n’importe quelle couche inférieure. Cela supprime le code répétitif, mais un changement dans la couche du bas peut alors affecter toutes les couches au-dessus. Beaucoup de systèmes réels mélangent les deux, en marquant certaines couches comme ouvertes, par exemple une couche partagée de journalisation ou d’utilitaires que tout le monde peut utiliser.

L’organisation en couches classique a une faiblesse notoire : la couche domaine dépend de la couche persistance, si bien que les règles métier les plus importantes dépendent de détails de base de données. Les architectures hexagonale, en oignon et Clean Architecture (section 5.6) appliquent l’inversion des dépendances pour y remédier : le domaine possède des interfaces comme OrderRepository, et le code de persistance les implémente, si bien que toutes les dépendances de code source pointent vers l’intérieur, vers le domaine.

Vérifier automatiquement les règles de dépendance

Les règles de dépendance écrites uniquement dans un wiki sont enfreintes en quelques semaines. Le moyen fiable de les faire respecter est de les exprimer sous forme de vérifications exécutables qui tournent dans le build et le font échouer quand une règle est enfreinte. Une telle vérification est une fonction d’aptitude (fitness function) architecturale, une idée présentée dans la section 2.8 et développée dans la section 11.3. Trois outils open source largement utilisés couvrent les principaux écosystèmes.

ArchUnit (Java et autres langages de la JVM) vous permet d’écrire des règles d’architecture sous forme de tests unitaires ordinaires : quels paquets peuvent accéder à quels autres, définitions de couches, et absence de cycles entre tranches de la base de code. dependency-cruiser (JavaScript et TypeScript) analyse les imports et les valide par rapport aux règles d’un fichier de configuration, et sa configuration de départ interdit déjà les dépendances circulaires. import-linter (Python) vérifie des contrats déclarés dans un fichier de configuration ; ses types de contrats couvrent notamment les imports interdits, les couches, l’indépendance entre modules frères, les modules protégés et l’acyclicité entre modules frères.

@ArchTest
static final ArchRule layers = layeredArchitecture()
    .consideringAllDependencies()
    .layer("Web").definedBy("..web..")
    .layer("Domain").definedBy("..domain..")
    .layer("Persistence").definedBy("..persistence..")
    .whereLayer("Web").mayNotBeAccessedByAnyLayer()
    .whereLayer("Domain").mayOnlyBeAccessedByLayers("Web", "Persistence")
    .whereLayer("Persistence").mayNotBeAccessedByAnyLayer();

@ArchTest
static final ArchRule noCycles =
    slices().matching("com.shop.(*)..").should().beFreeOfCycles();

// .dependency-cruiser.js
module.exports = {
  forbidden: [
    { name: "no-circular", severity: "error",
      from: {}, to: { circular: true } },
    { name: "domain-not-to-db", severity: "error",
      comment: "Domain code must use repository interfaces, not the database",
      from: { path: "^src/domain" },
      to: { path: "^src/db" } },
  ],
};

# .importlinter
[importlinter]
root_package = shop

[importlinter:contract:layers]
name = Web above domain above adapters
type = layers
layers =
    shop.web
    shop.domain
    shop.adapters

[importlinter:contract:features-independent]
name = Feature packages do not import each other
type = independence
modules =
    shop.catalogue
    shop.ordering
    shop.payments

Remarquez que la règle ArchUnit ci-dessus permet à Persistence d’accéder à Domain, mais pas l’inverse : c’est la disposition centrée sur le domaine qui vient d’être décrite, et non l’organisation en couches classique. Des règles comme celles-ci coûtent peu à ajouter, s’exécutent en quelques secondes et transforment un schéma d’architecture en quelque chose que le build défend. Quand une base de code existante enfreint déjà une règle, la plupart des outils peuvent enregistrer les infractions actuelles comme référence et n’échouer que sur les nouvelles, si bien que la règle empêche la situation de s’aggraver dès le jour où elle est introduite.

Comment les professionnels gèrent les dépendances

Les architectes expérimentés gardent une image du graphe des dépendances entre composants et la consultent régulièrement, en la générant à partir du code plutôt qu’en la dessinant à la main. Ils décident quels composants sont censés être stables (concepts du domaine, contrats partagés) et lesquels sont volatils (interfaces utilisateur, intégrations), et font pointer les flèches du volatil vers le stable. Ils traitent les nouveaux cycles comme des échecs du build, et non comme des questions de style. Et ils appliquent le même raisonnement entre services : les bibliothèques partagées et les schémas d’événements partagés sont les composants stables d’un système distribué, qui méritent des surfaces minimales et un versionnement soigné, tandis que l’intérieur de chaque service reste libre de changer.

Rien de tout cela n’exige de calculer les métriques avec précision. Leur valeur tient aux questions qu’elles obligent à poser : dans quel sens cette flèche doit-elle pointer, qu’arrive-t-il à tout ce qui est en amont si ceci change, et ce composant est-il aussi abstrait que l’exige le nombre d’éléments qui dépendent de lui ? La section 3.5 poursuit avec les principes SOLID, qui appliquent les mêmes idées à l’intérieur des composants et entre eux.