Garder un module autonome : repérer les dépendances qui compliquent les changements

Une petite modification du panier demande maintenant de changer trois modules. Pour comprendre une règle, il faut suivre des appels dans toute l'application. Ce sont des signes que les responsabilités se sont dispersées. Examiner quelques situations concrètes permet de corriger le découpage avant que chaque évolution devienne difficile.

Un même mot recouvre plusieurs besoins

Le « client » de l'inscription possède des identifiants de connexion. Celui de la facturation possède une adresse et des informations de paiement. Le mot est identique, mais les responsabilités diffèrent.

Cette différence n'est pas un défaut en soi : elle peut justifier des modèles distincts. Le problème apparaît lorsqu'une classe commune tente de répondre à tous les usages et change pour des raisons sans rapport entre elles.

Définissez alors ce que chaque module entend par ce terme. Des noms plus précis ou des contrats limités peuvent éviter de partager tout le modèle.

Deux modules dépendent mutuellement de leurs détails

Le panier importe les classes internes des commandes, tandis que les commandes importent celles du panier. Ce cycle rend plus difficile la compréhension et le test séparé de chaque partie.

Avant d'ajouter un nouvel appel, demandez quelle responsabilité crée ce besoin. Plusieurs réponses sont possibles :

• Déplacer une règle et les données qu'elle gouverne dans le même module.
• Définir une interface qui oriente la dépendance dans un sens clair.
• Publier un événement si le destinataire doit seulement réagir à un fait.
• Extraire un petit contrat ou une responsabilité commune réellement partagée.

Un événement ne supprime pas magiquement la dépendance métier. Il change la manière de la porter et peut ajouter un délai. Le choix doit simplifier le parcours, pas seulement faire disparaître une flèche du diagramme.

Les règles sont éloignées des données qu'elles protègent

Un module « Panier » conserve des lignes, mais d'autres modules calculent ses remises et modifient directement ses quantités. Chaque consommateur doit alors connaître les mêmes règles, avec le risque de les appliquer différemment.

Ce qui compte est d'identifier le responsable de la décision. Le regroupement des règles peut passer par des objets métier ou par des fonctions dédiées. Un style de programmation fonctionnel ou une séparation entre données et traitements ne constitue pas, à lui seul, un défaut d'architecture.

Si une opération demande sans cesse tous les objets internes d'un voisin, examinez la frontière. Un contrat plus adapté peut suffire ; parfois, déplacer la responsabilité et ses données est plus simple.

Un module change pour trop de raisons

Un module qui gère à la fois les stocks, les factures et les notifications peut devenir difficile à modifier. Pour le vérifier, regardez les changements récents : concernent-ils un même besoin ou plusieurs sujets indépendants ?

La taille du code donne un indice, mais ne tranche pas seule. Un module volumineux peut rester cohérent ; un petit module peut concentrer des dépendances problématiques.

Un composant utilisé partout mérite aussi un examen. Une bibliothèque stable peut remplir ce rôle correctement. Un module métier qui change souvent et oblige tous ses consommateurs à suivre devient plus préoccupant.

Distinguer la valeur métier de la place dans le graphe

Le core domain du DDD désigne ce qui apporte une valeur distinctive à l'activité. Il n'est pas défini par le nombre de dépendances qui pointent vers lui. Un dossier nommé « core » peut, lui, ne contenir que des utilitaires.

Ces noms ne permettent donc pas de décider si un partage est pertinent. Examinez les responsabilités, leur stabilité et les changements qu'elles imposent aux autres.

Rendre les limites vérifiables

Le langage, les modules de compilation et la visibilité des types peuvent limiter les imports autorisés. Des tests d'architecture, comme ceux proposés par ArchUnit, peuvent détecter les cycles et les accès à des classes internes.

Ces contrôles complètent la revue de conception. Ils vérifient une règle explicite, mais ne peuvent pas décider seuls si la frontière métier est bien placée.

Pour un module donné, définissez ses points d'entrée, ses données et les dépendances permises. Puis vérifiez une modification réelle : peut-elle rester locale ? Cette observation donne un critère plus utile qu'un nombre idéal de modules.

Le monolithe modulaire facilite ces ajustements en conservant un déploiement commun. Il permet de faire évoluer les frontières avant d'envisager une séparation en services.

Sources

• B. Foote & J. Yoder, Big Ball of Mud, 1997, révisé en 1999.
• M. Fowler, Bounded Context, 2014.
• E. Evans, Domain-Driven Design Reference, 2015.
• R. C. Martin, Granularity, The C++ Report, 1996.
• M. Fowler, Anemic Domain Model, 2003.
• ArchUnit.
• JEP 261, Module System.