Méthode de développement d’un module

Statut documentaire : guide — voir Maturité et preuves.

Démarrage : partir des faits métier et non des écrans

Le développement d’un module doit commencer par l’observation des faits métier, c’est-à-dire des situations réellement rencontrées par les utilisateurs, par les gestionnaires et par les processus de l’organisation. À ce stade, l’équipe ne cherche ni à dessiner des écrans ni à dresser des listes de tables. Elle cherche à identifier ce qui existe durablement, ce qui joue un rôle contextuel, ce qui relie des entités entre elles, ce qui constitue un événement significatif et ce qui relève d’une contrainte de validité dans le temps. Cette première étape produit une matière brute qui doit ensuite être raffinée.

La transformation de cette matière brute commence par la construction d’un glossaire contrôlé. Chaque terme y reçoit une définition dense, formulée de manière à éviter les synonymies implicites et les superpositions de sens. Il faut préciser pour chaque concept ce qui lui donne son identité, ce qui le distingue d’un concept proche, quels attributs sont structurels, quelles relations lui sont essentielles et quel est son comportement dans le temps. Cette phase est souvent sous-estimée alors qu’elle conditionne la qualité de tout le reste. Tant qu’un terme comme « inscription », « responsable », « dossier », « présence » ou « partie » n’est pas clarifié, toute implémentation reste fragile.

Classification selon les trois niveaux ontologiques

Une fois le glossaire initial produit, chaque concept candidat doit être classé dans l’un des trois niveaux ontologiques. Cette classification n’est pas décorative ; elle gouverne la manière dont le concept sera implémenté, documenté, réutilisé et protégé contre les contaminations de domaine. Lorsqu’un concept prétend être fondationnel, l’équipe doit démontrer qu’il possède une valeur transversale indépendamment d’un secteur particulier. S’il est transverse métier, il faut montrer qu’il correspond à un pattern récurrent observable dans plusieurs familles de processus. S’il est sectoriel, il doit apparaître comme la spécialisation d’un concept inférieur et non comme un noyau autonome.

Dans la pratique, cette classification s’effectue lors d’un atelier d’architecture sémantique. L’équipe parcourt les concepts un par un, vérifie leur niveau, identifie leur filiation et note explicitement les raisons du classement. Ce travail est fondamental, car il évite les erreurs classiques, comme la remontée de concepts trop spécialisés dans le noyau, ou à l’inverse l’introduction d’abstractions tellement génériques qu’elles ne portent plus aucun invariant utile.

Construction du modèle conceptuel

Lorsque les concepts sont classés, le module peut être modélisé. Le premier travail consiste à identifier les relations de spécialisation, puis les associations structurelles, puis les participations contextuelles, puis les dépendances temporelles. Cette séquence est importante. La spécialisation permet de savoir ce qui « est un ». Les associations structurelles expriment les liens permanents ou quasi permanents entre concepts. Les participations contextuelles permettent d’exprimer qu’une entité prend part à un accord, une inscription, une évaluation, une activité ou une organisation. Les dépendances temporelles expriment quant à elles la validité, la date d’effet, la révision ou l’historisation.

Le modèle conceptuel doit ensuite être relu à travers une question centrale : quels sont les invariants ? Un invariant est une proposition qui doit rester vraie à tout instant du cycle de vie du module. Si le modèle ne permet pas d’identifier d’invariants, il est probablement trop faible ou trop descriptif. Dans un module party, un exemple d’invariant serait l’unicité d’un identifiant primaire actif dans un schéma donné ou l’impossibilité pour une relation active de référencer une partie inexistante. Dans un module d’inscription, l’invariant peut porter sur l’unicité d’une inscription valide pour une combinaison donnée à une date donnée.

Définition des cycles de vie et des événements de domaine

Une fois les invariants identifiés, il faut décrire le comportement dynamique des concepts majeurs. Cette étape commence par la définition des cycles de vie. Chaque concept structurant doit être associé à un ensemble d’états métier et à des transitions autorisées. Il ne s’agit pas de statuts décoratifs pour interface utilisateur, mais de véritables états du domaine. On précisera donc ce qui fait passer une entité de Draft à Active, de PendingValidation à Rejected, de Active à Suspended, ou de Suspended à Archived, ainsi que les préconditions attachées à chaque transition.

À partir de ces transitions, on formalise les événements de domaine. Un événement correspond à un fait métier significatif que les autres modules ont potentiellement besoin de connaître. La règle ici est de ne pas publier des événements trop techniques, mais des événements exprimant une transformation du domaine. PartyRoleAssigned, IdentifierVerified, PartyRelationshipCreated, PartyStatusChanged ou EnrollmentValidated sont de bons exemples, car ils portent une sémantique lisible. À l’inverse, des événements comme RowUpdated ou TableRecordModified n’ont aucune valeur métier et ne doivent pas servir de contrats inter-modules.

Définition des agrégats et des frontières transactionnelles

Le module doit ensuite être structuré en agrégats. Un agrégat est l’unité au sein de laquelle les invariants doivent être maintenus immédiatement. Cette notion est essentielle pour éviter les transactions diffuses et les dépendances implicites. La délimitation des agrégats ne se déduit pas mécaniquement du diagramme conceptuel ; elle dépend du comportement attendu du système. Il faut se demander quelles entités doivent évoluer de manière cohérente, quelles opérations doivent être atomiques et quels éléments peuvent être synchronisés de façon asynchrone.

Dans certains cas, le concept principal du module sera la racine naturelle d’agrégat. Dans d’autres, certains objets associés devront être externalisés pour des raisons de volumétrie, de fréquence de modification ou de cycle de vie autonome. La bonne pratique consiste à choisir des frontières transactionnelles petites mais sémantiquement solides, et à s’appuyer sur les événements de domaine pour propager l’information hors de ces frontières.

Projection technique vers le modèle d’implémentation

Ce n’est qu’après les étapes précédentes que le module peut être projeté vers son implémentation technique. La projection consiste à traduire les concepts en classes, facettes, tables, générateurs d’identifiants, collections, actions et services. Cette traduction doit rester fidèle à la structure ontologique. On ne doit jamais résoudre un besoin purement technique en déformant le sens du modèle. Si un concept nécessite une table séparée pour des raisons d’indexation, cela ne signifie pas nécessairement qu’il devient un agrégat autonome. Si un champ composite doit être dénormalisé pour accélérer une recherche, cela ne doit pas masquer l’existence d’une relation conceptuelle distincte.

Dans un environnement utilisant des classes XML, des facettes hypergraphes et des facettes de persistance, chaque concept central doit être décrit par un jeu minimal de champs identitaires, de champs sémantiques, de champs temporels et de champs de statut. Les collections exposées par le module doivent être construites comme des vues de navigation ou de recherche, non comme des portes d’accès directes qui court-circuiteraient les invariants du domaine. Les actions définies sur les objets doivent exprimer des intentions métier complètes. Enfin, les services applicatifs doivent rester des orchestrateurs ; ils n’ont pas vocation à contenir une logique qui devrait appartenir aux entités ou aux règles de domaine.

Vérification et tests

Le développement se termine par une phase de vérification qui ne doit pas se limiter à des tests CRUD. Les tests doivent valider les invariants, les transitions de cycle de vie, les cas de concurrence pertinents, la cohérence des historiques et la publication des événements de domaine. Pour chaque action métier, il faut vérifier au minimum les préconditions, les effets de bord autorisés, la cohérence transactionnelle et l’état final de l’agrégat. Lorsqu’un module se positionne dans un niveau fondationnel ou transverse, il faut également vérifier qu’il peut être exploité sans dépendre d’une spécialisation sectorielle implicite.

Une pratique utile consiste à maintenir, en plus des tests unitaires et d’intégration, un petit corpus de scénarios documentés qui rejouent les transformations métier majeures du module. Ces scénarios servent à la fois de documentation exécutable et de garde-fou contre les dérives sémantiques lors des évolutions futures.