Comment les DSLs communiquent📋

SOLID, architecture hexagonale et événements typés — le génie logiciel de 2026 appliqué à la gestion de la loi

Compagnon de : Qu'est-ce qu'un DSL ? et Appareil et compilateur Auteur : Stéphane Erard — 10 avril 2026

« Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". » — Doug McIlroy, Unix Philosophy, 1978

« Expect the output of every program to become the input to another, as yet unknown, program. » — Doug McIlroy, ibid.

Sommaire📋

1. Avertissement au lecteur
2. Le problème : des DSLs qui ne doivent pas fusionner
3. Trois principes du génie logiciel
4. SOLID — cinq règles de bonne conduite entre composants
5. Architecture hexagonale — le noyau et ses ports
6. Événements typés — le colis et le facteur
7. SOLID appliqué au droit
8. Architecture hexagonale appliquée au droit
9. Événements typés appliqués au droit
10. Le colis de chaque DSL : le package séparé
11. Synthèse : trois acteurs, trois architectures
12. Le vocabulaire à retenir

1. Avertissement au lecteur📋

Cette page suppose que le lecteur sait ce qu'est un DSL. Si ce n'est pas le cas, lire d'abord Qu'est-ce qu'un DSL ?.

Le sujet ici est le suivant : la page précédente a montré que le projet métacratie construit plusieurs DSLs — Law.Dsl, Commons.Dsl, Citizen.Dsl, Common.Dsl. Plusieurs, pas un seul. Et la question naturelle est : comment ces DSLs se parlent-ils ? Comment le DSL du droit sait-il que le DSL des biens communs a changé ? Comment le DSL du citoyen reçoit-il les informations du DSL juridique sans être soudé à lui ?

La réponse vient de trois principes fondamentaux du génie logiciel, pratiqués quotidiennement dans l'industrie en 2026. Cette page les présente d'abord dans leur forme générale, avec des analogies accessibles, puis les traduit en gestion de la loi et en rapport citoyen/État/administration.

2. Le problème : des DSLs qui ne doivent pas fusionner📋

Pourquoi plusieurs DSLs et pas un seul ?📋

La tentation naïve serait de construire un seul méga-langage qui contiendrait tout : le vocabulaire juridique, le vocabulaire des biens communs, le vocabulaire citoyen, le vocabulaire technique. Un « esperanto du droit ».

C'est exactement ce qu'il ne faut pas faire. Pour trois raisons.

Première raison : l'explosion de la complexité. Si chaque domaine a 100 concepts et que l'on fusionne quatre domaines en un seul langage, on n'obtient pas 400 concepts — on obtient 400 concepts plus toutes les interactions possibles entre eux, soit potentiellement 400 × 399 = 159 600 paires. La complexité n'est pas additive, elle est combinatoire. Quatre DSLs séparés, chacun avec 100 concepts et des points de contact explicites entre eux, sont infiniment plus maîtrisables.

Deuxième raison : l'indépendance des évolutions. Le droit change à son rythme (une loi peut être amendée du jour au lendemain). Le statut politique des biens communs change à un autre rythme (le débat sur la privatisation de l'eau dure des décennies). Les droits citoyens changent encore à un autre rythme. Si tout est dans un seul langage, le moindre changement dans un domaine risque de casser les autres. Des DSLs séparés peuvent évoluer indépendamment.

Troisième raison : la lisibilité par domaine. Un juriste veut lire le vocabulaire juridique sans être noyé dans le vocabulaire technique des biens communs. Un citoyen veut comprendre ses droits sans devoir maîtriser la hiérarchie des normes. Chaque DSL s'adresse à son public.

Le vrai problème📋

Le problème n'est donc pas « comment tout mettre ensemble », mais « comment faire communiquer des choses séparées sans les souder ». C'est le problème central de l'architecture logicielle depuis cinquante ans. Et le génie logiciel a produit trois réponses, indépendantes et complémentaires, que je vais présenter.

3. Trois principes du génie logiciel📋

Les trois principes qui résolvent le problème de la communication entre composants indépendants sont :

1. SOLID — cinq règles qui garantissent que chaque composant fait une seule chose, bien, et qu'on peut le remplacer sans tout casser.

2. L'architecture hexagonale (dite aussi « ports et adaptateurs ») — une structure qui sépare le cœur du domaine (la logique pure) des points d'entrée et de sortie (les interfaces avec le monde extérieur).

3. L'architecture événementielle — un mécanisme de communication où les composants s'envoient des messages typés (des « événements ») sans se connaître mutuellement.

Chacun de ces principes répond à une facette du problème. SOLID dit comment construire chaque composant. L'hexagonal dit comment structurer les relations entre le cœur et l'extérieur. Les événements disent comment communiquer entre composants sans les coupler.

Je vais d'abord les présenter dans leur forme logicielle, avec des analogies du quotidien. Puis je les traduirai, un par un, en gestion de la loi.

4. SOLID — cinq règles de bonne conduite entre composants📋

SOLID est un acronyme proposé par Robert C. Martin au début des années 2000. Chaque lettre est une règle de conception. Je les traduis ici en langage courant.

S — Responsabilité unique (Single Responsibility)📋

Chaque composant fait une chose et une seule.

La caisse enregistreuse d'un supermarché calcule le total et imprime le ticket. Elle ne gère pas le stock, ne commande pas les réapprovisionnements, ne calcule pas les salaires des employés. Si l'on veut changer la politique de remises, on modifie la caisse — et rien d'autre ne casse.

En logiciel : chaque module, chaque fichier, chaque package a un domaine de responsabilité. Pas deux.

O — Ouvert/Fermé (Open/Closed)📋

Un composant est ouvert à l'extension, fermé à la modification.

Quand on ajoute une prise USB-C à un ordinateur portable, on ne démonte pas la carte mère pour la ressouder. On utilise un port prévu à cet effet. Le port est ouvert à de nouveaux périphériques, mais la carte mère est fermée — on ne la modifie pas.

En logiciel : on peut ajouter de nouveaux comportements (des extensions) sans toucher au code existant, grâce à des points d'extension prévus à l'avance.

L — Substitution de Liskov (Liskov Substitution)📋

Tout remplaçant doit tenir les mêmes promesses.

Si un restaurant promet « poisson frais du jour » au menu, le client s'attend à du poisson, qu'il s'agisse de bar, de dorade ou de sole. Le restaurant peut changer l'espèce selon l'arrivage (c'est la substitution), mais il ne peut pas servir du poulet à la place (c'est la violation de la promesse).

En logiciel : si un composant dit « je suis un Law.Dsl », tout code qui utilise un Law.Dsl doit fonctionner avec n'importe quelle instance — Law.France2026.Dsl, Law.UE2024.Dsl, ou toute autre.

I — Ségrégation des interfaces (Interface Segregation)📋

Ne pas forcer un client à dépendre de choses qu'il n'utilise pas.

À la poste, le guichet « envoi de colis » ne vous oblige pas à ouvrir un compte bancaire. Le guichet « services financiers » ne vous oblige pas à acheter des timbres. Chaque guichet offre une interface minimale, adaptée à un besoin précis.

En logiciel : les interfaces (les « contrats » entre composants) doivent être petites et spécialisées. Un composant qui a besoin de lire un article de loi ne devrait pas être obligé de dépendre d'un composant qui sait aussi modifier les articles, calculer les statistiques et générer des rapports.

D — Inversion des dépendances (Dependency Inversion)📋

Les règles de haut niveau ne doivent pas dépendre des détails techniques.

La Constitution française ne dit pas « le droit de vote sera exercé sur des machines Diebold modèle AccuVote-TS fabriquées en 2003 ». Elle dit « le suffrage est universel, égal et secret ». Le principe (le suffrage universel) ne dépend pas du détail technique (le mécanisme de vote). On peut changer le mécanisme — bulletin papier, machine, vote électronique — sans toucher au principe.

En logiciel : les modules de haut niveau (les règles du domaine) dépendent d'abstractions (des interfaces), pas de détails concrets. Les détails concrets (la base de données, l'interface graphique, le réseau) dépendent eux aussi des abstractions. Tout le monde dépend du contrat, personne ne dépend de l'implémentation.

5. Architecture hexagonale — le noyau et ses ports📋

L'architecture hexagonale a été proposée par Alistair Cockburn en 2005 sous le nom de Ports and Adapters. L'idée est simple et profonde.

Le noyau📋

Au centre, il y a le noyau : la logique pure du domaine. Le noyau ne connaît ni base de données, ni écran, ni réseau, ni fichier. Il ne sait pas d'où viennent les données ni où vont les résultats. Il sait seulement appliquer les règles du domaine.

L'analogie : le moteur d'une voiture produit un couple mécanique. Il ne sait pas s'il est dans une berline, un SUV ou un bateau. Il fait une chose : convertir du carburant en rotation.

Les ports📋

Autour du noyau, il y a des ports : des ouvertures standardisées par lesquelles le noyau communique avec l'extérieur. Un port est une interface — un contrat qui dit « je peux recevoir telle information » ou « je peux fournir tel résultat ».

L'analogie : les prises de courant normalisées. Une prise CEE 7/5 (la prise française) est un port. N'importe quel appareil compatible peut s'y brancher. La prise ne sait pas si l'appareil est un grille-pain ou un ordinateur.

Les adaptateurs📋

Derrière chaque port, il y a un adaptateur : un composant concret qui connecte le port à un système externe spécifique. Si le port dit « je reçois des données juridiques », l'adaptateur peut être : un fichier XML du Journal officiel, une API REST de Légifrance, une base de données interne, ou un test avec des données fictives.

L'analogie : les chargeurs de téléphone. Le port USB-C est le même pour tous. L'adaptateur peut être un chargeur mural (prise secteur → USB-C), un chargeur de voiture (allume-cigare → USB-C), ou un câble branché sur un ordinateur (USB-A → USB-C). Le téléphone ne sait pas lequel est branché — il reçoit du courant par le port, point.

Pourquoi ça compte📋

La force de l'hexagone est la testabilité et la substituabilité. On peut tester le noyau sans base de données (en branchant un adaptateur fictif sur le port). On peut changer de base de données sans toucher au noyau (en écrivant un nouvel adaptateur). On peut même avoir plusieurs adaptateurs actifs en même temps — le même noyau juridique peut être consulté via une API web, via une ligne de commande, et via un éditeur de texte spécialisé, simultanément.

6. Événements typés — le colis et le facteur📋

Le principe📋

Dans une architecture événementielle, les composants ne s'appellent pas directement. Ils publient des événements — des messages structurés qui décrivent ce qui vient de se passer — et d'autres composants, intéressés par ces événements, les reçoivent et réagissent.

L'analogie la plus directe est le service postal.

Quand vous déménagez, vous envoyez un faire-part de changement d'adresse. Vous ne téléphonez pas individuellement à la banque, à l'assurance, à la mutuelle, à la Sécurité sociale, au fournisseur d'électricité et à votre grand-mère. Vous publiez un message — « j'ai changé d'adresse, voici la nouvelle » — et chaque destinataire intéressé le reçoit et agit en conséquence. La banque met à jour votre dossier. L'assurance recalcule votre prime. Votre grand-mère vous envoie un bouquet de fleurs. Chacun réagit à sa manière, selon ses propres règles, sans que vous ayez besoin de connaître ces règles.

Trois propriétés essentielles📋

L'événement est typé. Ce n'est pas un message libre en prose. C'est un formulaire structuré avec des champs précis. Un événement « changement d'adresse » contient : l'identité de la personne, l'ancienne adresse, la nouvelle adresse, la date d'effet. Pas de place pour l'ambiguïté.

L'émetteur ne connaît pas les destinataires. Vous publiez l'événement. Vous ne savez pas qui le lit. Demain, un nouveau service peut s'abonner à vos événements sans que vous ayez à changer quoi que ce soit de votre côté. C'est le découplage.

Le destinataire ne connaît pas l'émetteur. L'assurance sait qu'elle a reçu un événement « changement d'adresse ». Elle n'a pas besoin de savoir comment cet événement a été produit — par un formulaire papier, par un site web, ou par un appel téléphonique. Elle traite le contenu de l'événement, pas son origine.

Le colis séparé📋

Dans la pratique logicielle de 2026, la définition de l'événement (ses champs, sa structure, ses types) est publiée dans un package séparé — un colis indépendant que tout le monde peut télécharger et référencer. Ce package ne contient ni logique, ni base de données, ni interface graphique. Il contient uniquement la forme du message : « un événement de changement d'adresse a cette structure ».

C'est exactement comme un formulaire Cerfa : le formulaire est un document standard, distribué séparément, que n'importe quelle administration peut utiliser. L'administration ne crée pas le formulaire — elle le consomme. Et le service qui a créé le formulaire ne sait pas quelles administrations l'utilisent.

7. SOLID appliqué au droit📋

Les cinq principes SOLID ne sont pas une curiosité d'informaticien. Appliqués à la gestion de la loi, ils décrivent exactement les propriétés qu'un système juridique sain devrait avoir — et qu'il n'a, aujourd'hui, que partiellement.

S — Un texte de loi, une responsabilité📋

Aujourd'hui, une loi fourre-tout (les fameuses « lois portant diverses dispositions ») mélange des amendements sur le droit du travail, des modifications fiscales, des dispositions environnementales et des ajustements de procédure pénale dans un seul texte. C'est la violation directe du principe de responsabilité unique.

En DSL : Law.Dsl ne contient que le vocabulaire juridique. Commons.Dsl ne contient que le vocabulaire des biens communs. Citizen.Dsl ne contient que le vocabulaire citoyen. Chaque DSL a un domaine de responsabilité. Si l'on veut modifier le statut politique de l'eau potable, on touche Commons.Dsl — et Law.Dsl n'est pas affecté, sauf aux points de contact explicites (les bridges).

L'analogue institutionnel : chaque commission parlementaire devrait avoir un scope clairement délimité, et un texte de loi ne devrait traverser qu'une seule commission de fond — pas trois en parallèle avec des amendements croisés incompatibles.

O — Ouvert à l'extension, fermé à la modification📋

Le droit français pratique déjà partiellement ce principe : la Constitution est fermée à la modification (révision constitutionnelle = procédure lourde, Congrès à Versailles) mais ouverte à l'extension (lois organiques, lois ordinaires qui précisent les principes constitutionnels).

En DSL : Law.Dsl (la racine) définit les concepts abstraits — article, alinéa, hiérarchie des normes. Il ne change presque jamais. Les instances — Law.France2026.Etalab.Dsl, Law.UE2024.Dsl — sont des extensions qui utilisent ces concepts sans les modifier. Le Root est fermé ; les instances sont ouvertes.

Ce que le compilateur apporte : il vérifie que les extensions respectent les contraintes du Root. Si une instance essaie d'introduire un concept qui viole une contrainte de la racine, le compilateur produit une erreur — exactement comme le Conseil constitutionnel devrait détecter qu'une loi organique viole un principe constitutionnel.

L — Tout cadre juridique substitutable📋

Si le système promet « je vérifie un cadre juridique conforme à Law.Dsl », il doit fonctionner aussi bien avec le droit français de 2024 qu'avec le droit européen de 2024 ou le droit français de 1995. Chaque instance est substituable tant qu'elle respecte le contrat de la racine.

L'analogue institutionnel : un citoyen qui change de région ne devrait pas avoir à réapprendre l'intégralité du système juridique. Les lois locales varient, mais le cadre national est le même. Le contrat (le Code civil, la Constitution) est respecté par toutes les instances locales.

I — Des interfaces minimales pour chaque acteur📋

Un citoyen qui consulte ses droits n'a pas besoin de l'interface complète du législateur. Un juge qui vérifie la constitutionnalité d'une loi n'a pas besoin de l'interface du citoyen qui dépose un recours. Chaque acteur a besoin d'une vue minimale du système — une interface ségrégée, adaptée à son rôle.

En DSL : le package Citizen.Dsl expose une interface de lecture et de recours. Le package Law.Dsl expose une interface de rédaction et de vérification. Le package Commons.Dsl expose une interface de classification et de débat. Personne n'est forcé de dépendre de ce qui ne le concerne pas.

D — La loi dépend de principes, pas de détails techniques📋

La Constitution ne mentionne pas « la base de données Oracle du ministère de la Justice ». Elle énonce des principes. Les détails techniques (comment stocker, comment transmettre, comment afficher) sont des adaptateurs — interchangeables sans toucher aux principes.

En DSL : Law.Dsl dépend d'abstractions (interfaces comme ILawCorpusLoader, ICadreValidator). Les détails concrets — Roslyn, fichiers XML, API REST — sont des adaptateurs injectés. On peut changer toute l'infrastructure technique sans modifier une seule ligne du DSL juridique.

8. Architecture hexagonale appliquée au droit📋

L'hexagone se traduit directement en architecture institutionnelle.

Le noyau : la logique juridique pure📋

Au centre de l'hexagone juridique, il y a la logique pure du droit : les règles de validité, la hiérarchie des normes, les conditions d'application d'un article, les contraintes de cohérence entre articles. Ce noyau ne sait pas d'où viennent les textes (du Journal officiel, d'un éditeur juridique, d'un brouillon parlementaire) ni qui les consulte (un juge, un citoyen, un chercheur, un robot). Il sait seulement vérifier : « ce texte est-il conforme à la hiérarchie des normes ? cet article entre-t-il en contradiction avec cet autre article ? »

Dans le codebase du projet, ce noyau s'appelle Bridge.Core — un module pur, sans dépendance technique, qui contient les identifiants typés (ArticleFqn, AlineaFqn, AssetFqn, SpaceFqn, PeriodFqn), le détecteur de franchissement de frontière (FrontierCrossingDetector), les gardes, et les verdicts. Rien d'autre.

Les ports : ce que le droit attend du monde📋

Autour du noyau, les ports sont les ouvertures par lesquelles le droit communique avec la réalité :

• Port d'entrée « corpus juridique » : « donne-moi les textes de loi applicables dans cette juridiction à cette date ». L'interface ILawCorpusLoader — une question, pas une implémentation.
• Port d'entrée « données factuelles » : « donne-moi les mesures de CO₂, les indicateurs économiques, les données démographiques ». Le droit a besoin de faits pour vérifier ses conditions d'application.
• Port de sortie « diagnostic » : « voici les incohérences détectées, les violations de la hiérarchie des normes, les articles en conflit ». Le noyau produit des verdicts ; il ne sait pas comment ils seront affichés.
• Port de sortie « simulation » : « voici ce qui se passerait si l'on modifiait l'article X ». Le noyau calcule ; il ne sait pas qui a demandé la simulation.

Les adaptateurs : trois interfaces pour trois mondes📋

Derrière chaque port, un adaptateur connecte le noyau au monde réel :

• Adaptateur « compile-time » (le Source Generator) : vérifie la cohérence au moment de la compilation, avant même que le code ne soit exécuté. C'est le contrôle a priori, l'équivalent du contrôle de constitutionnalité avant promulgation.
• Adaptateur « IDE-time » (l'Analyzer Roslyn) : vérifie en temps réel, pendant que le rédacteur écrit. Des soulignements rouges apparaissent sous les incohérences, comme un correcteur orthographique pour le droit. C'est l'assistance pendant la rédaction.
• Adaptateur « CLI » (la ligne de commande) : vérifie sur demande, en lot, pour un corpus entier. C'est l'audit a posteriori, l'équivalent d'un contrôle de la Cour des comptes.

Le noyau est le même dans les trois cas. Seul l'adaptateur change. Un juge constitutionnel, un parlementaire en train de rédiger, et un auditeur qui contrôle a posteriori utilisent la même logique de vérification — par des portes d'entrée différentes.

L'analogue citoyen📋

Pour le citoyen, l'hexagone se lit ainsi : le noyau est l'ensemble de ses droits et obligations tels qu'ils résultent du croisement de sa situation personnelle avec les cadres juridiques applicables. Les ports sont les questions qu'il peut poser (« ai-je droit à cette aide ? », « ce recours est-il recevable ? », « que se passe-t-il si cette loi est modifiée ? »). Les adaptateurs sont les canaux par lesquels il interagit : un site web, une application mobile, un guichet physique, un chatbot, un avocat. Le citoyen ne devrait pas avoir à comprendre comment le système fonctionne en interne — il pose une question par un port, et reçoit une réponse structurée.

9. Événements typés appliqués au droit📋

C'est ici que le rapport citoyen/État/administration prend sa forme la plus concrète.

Le problème actuel : la notification est informelle📋

Aujourd'hui, quand une loi est modifiée, comment le citoyen l'apprend-il ? Par le Journal officiel (que personne ne lit). Par les médias (qui simplifient). Par son expert-comptable (qui l'apprend lui-même par une circulaire). Par hasard. La chaîne de notification est informelle, lente, incomplète et non structurée.

L'administration, de son côté, apprend les changements par des circulaires internes — des documents en prose, ambigus, sujets à interprétation, dont l'application est vérifiée par... personne, ou par l'usager qui se plaint.

La solution : des événements typés📋

Dans le compilateur métacratique, chaque DSL peut publier des événements typés — des messages structurés qui décrivent ce qui vient de changer, avec des champs précis et vérifiables.

Événements de Law.Dsl :

• LawArticleAmended : un article a été modifié. Champs : identifiant de l'article (ArticleFqn), ancienne version, nouvelle version, date d'effet, juridiction, niveau dans la hiérarchie des normes.
• LawArticleRepealed : un article a été abrogé. Champs : identifiant, date d'abrogation, texte abrogeant.
• NormConflictDetected : une incohérence a été détectée entre deux normes. Champs : les deux articles en conflit, la nature du conflit, la gravité.

Événements de Commons.Dsl :

• AssetStatusChanged : le statut politique d'un bien a changé (par exemple : l'eau potable passe de « service marchand » à « bien commun »). Champs : identifiant du bien (AssetFqn), ancien statut, nouveau statut, texte fondateur du changement.
• CommonsContestationFiled : une contestation a été déposée sur le statut d'un bien. Champs : identifiant du bien, nature de la contestation, auteur.

Événements de Citizen.Dsl :

• CitizenCaseUpdated : un dossier citoyen a été mis à jour suite à un changement de cadre juridique. Champs : identifiant du citoyen, articles affectés, nouveau statut du droit.
• CitizenRecourseAvailable : un nouveau recours est devenu disponible. Champs : identifiant du citoyen, nature du recours, délai.

Qui publie, qui écoute ?📋

Le schéma est celui du service postal :

L'État publie les événements de Law.Dsl quand il modifie la loi. Il ne sait pas qui écoute. Il publie le message structuré, point.

L'administration écoute les événements de Law.Dsl pour mettre à jour ses procédures internes. Elle écoute aussi Commons.Dsl pour adapter la gestion des biens publics. Elle n'a pas besoin de téléphoner au législateur pour savoir ce qui a changé — l'événement typé lui arrive avec tous les détails nécessaires.

Le citoyen écoute (via l'adaptateur de son choix — site web, appli, chatbot) les événements qui le concernent. Quand Law.Dsl publie un événement LawArticleAmended sur un article qui affecte sa situation, son dossier Citizen.Dsl est automatiquement réévalué, et un événement CitizenCaseUpdated lui est adressé. Plus besoin d'attendre que l'expert-comptable lise la circulaire.

Le découplage comme garantie démocratique📋

Le découplage n'est pas une coquetterie technique. C'est une garantie démocratique.

Si le citoyen est directement couplé au système législatif (c'est-à-dire s'il doit connaître les détails internes de la production législative pour comprendre ses droits), alors seuls les citoyens qui ont les moyens de payer un juriste peuvent exercer leurs droits. L'asymétrie d'information devient une asymétrie de pouvoir.

Si le citoyen est découplé du système législatif par une couche d'événements typés et un adaptateur accessible, alors le même changement de loi produit le même message structuré pour tous les citoyens, quels que soient leurs moyens. L'expert-comptable et le bénéficiaire du RSA reçoivent le même événement LawArticleAmended — l'un le lit directement, l'autre le reçoit via un adaptateur simplifié, mais l'information est la même.

10. Le colis de chaque DSL : le package séparé📋

Le principe du package séparé📋

Dans l'écosystème .NET tel qu'il est pratiqué en 2026, chaque composant publie ses contrats (ses interfaces, ses types d'événements, ses structures de données) dans un package NuGet séparé — un colis distribuable, versionné, signé, que n'importe quel autre composant peut référencer sans dépendre de l'implémentation.

C'est la traduction technique directe de l'inversion des dépendances (le D de SOLID) : tout le monde dépend du contrat (le package), personne ne dépend de l'implémentation.

Traduit en architecture législative📋

Chaque DSL du compilateur métacratique produit trois packages séparés :

Le citoyen qui veut être notifié des changements de loi ne dépend pas du Code civil entier. Il dépend uniquement de Law.Dsl.Events — le package qui contient la forme des messages, pas le contenu législatif. C'est le formulaire Cerfa, pas l'administration.

De même :

La séparation des préoccupations (separation of concerns)📋

Chaque package a ses préoccupations (concerns) et rien d'autre :

• Le package racine (Law.Dsl) dit ce que le droit est — les concepts, les contraintes, les relations.
• Le package événements (Law.Dsl.Events) dit ce qui change — les messages structurés que les changements produisent.
• Le package instance (Law.France2026.Etalab.Dsl) dit ce qu'est le droit français en 2026 — le contenu concret.
• Le package bridge (Law.Commons.Bridge) dit comment deux DSLs se vérifient mutuellement — les règles de cohérence inter-domaines.

Personne ne dépend de tout. Chacun dépend de ce dont il a besoin, et de rien d'autre. C'est le principe de ségrégation des interfaces (le I de SOLID) appliqué à l'échelle de l'écosystème.

11. Synthèse : trois acteurs, trois architectures📋

Le tableau suivant résume comment les trois principes s'appliquent aux trois acteurs du rapport citoyen/État/administration.

12. Le vocabulaire à retenir📋