Sur cette page
Propriété d'architecture
COADF P-7 est publié en entier. Les systèmes de classification, les bases terminologiques et les services externes de validation vivent dans des modules adaptateurs, marqués comme tels, hors du modèle de données central. Un service externe peut élever la confiance d'un attribut ; aucun ne peut bloquer une sortie. Quand un service est indisponible, le système produit des éléments de preuve assortis d'une confiance moindre plutôt que rien ; quand une licence change, le cœur n'est pas touché ; et le contenu sous licence est marqué dans ses métadonnées et tenu à l'écart du cœur ouvert.
COADF ne publie pas la façon dont une réponse externe modifie la confiance, et elle n'est pas décrite ici. Les exemples consignent une réponse externe et son statut, et n'en font rien d'autre.
Pourquoi elle compte
Les normes et les vocabulaires survivent aux produits, changent de version selon leur propre calendrier, portent des conditions de licence et sont servis par des systèmes qu'on n'exploite pas soi-même. Chacun de ces traits est une voie par laquelle la décision de quelqu'un d'autre devient une panne ou une réécriture chez soi. La carte réglementaire de COADF nomme ECLASS et l'IEC Common Data Dictionary comme vocabulaires sous licence traités de cette façon ; le même raisonnement vaut pour un résolveur d'identifiants, un fournisseur de classification ou un service externe de validation qui a sa propre disponibilité.
Le domaine a besoin de leurs réponses. Il ne doit pas en avoir besoin pour fonctionner, et il ne doit pas se mettre à penser dans leurs termes.
Stratégies de mise en œuvre valables
- Port et adaptateur. Le domaine définit l'interface dont il a besoin, dans ses propres mots ; chaque système externe reçoit un adaptateur qui la met en œuvre.
- Couche anticorruption. L'adaptateur traduit le modèle externe dans le modèle du domaine et inversement, si bien que les concepts et les noms externes s'arrêtent à la bordure.
- Posséder ses identifiants. Le domaine garde sa propre identité pour un concept, et stocke un code externe comme une référence attribuée : le référentiel, la version du référentiel, le code, son origine, sa date, et s'il est sous licence.
- Épingler la version. Un code n'a de sens qu'à l'intérieur d'une version de son référentiel. Consigner la version avec chaque référence stockée et l'envoyer avec chaque consultation. Un nouveau transport ou une nouvelle représentation chez le fournisseur peut rester dans l'adaptateur ; une nouvelle version sémantique de la norme peut changer ce que signifient les codes, et la correspondance du domaine doit alors changer avec elle.
- Une absence explicite. Un service indisponible donne un « non disponible » consigné, jamais une valeur par défaut et jamais une chaîne de traitement bloquée. Chaque appel a un délai d'expiration, et le chemin critique n'attend pas un enrichissement dont il peut se passer.
- Marquer le contenu sous licence. Chaque valeur stockée issue d'une source sous licence porte un marqueur, pour que les exports, les journaux, les caches et les artefacts publics puissent l'écarter mécaniquement.
- Une frontière de plugins là où les adaptateurs sont facultatifs ou fournis par des tiers : chargés via un registre dont le domaine ne dépend pas.
En Python, le port peut être un typing.Protocol, vérifié par les vérificateurs de types statiques ; un contrôle isinstance à l'exécution contre lui exige @runtime_checkable et vérifie seulement que les méthodes existent, pas leurs signatures. C'est le test de contrat qui vérifie le comportement.
Modes de défaillance
Chaque défaillance qualifiée de panne
Un délai dépassé, des identifiants révoqués, une requête mal formée et une réponse sous une forme nouvelle, tous signalés comme « indisponible ». La panne se résorbe d'elle-même ; l'intégration cassée est relancée indéfiniment et jamais réparée. Il faut au minimum distinguer l'introuvable, l'indisponibilité passagère et l'intégration rejetée, dans les termes propres de l'adaptateur, pas dans les codes de statut du fournisseur.
Des classes externes qui fuient à travers le domaine
Les types du fournisseur apparaissent dans les signatures du domaine, puis dans le schéma de la base de données, puis dans l'API publique.
Le SDK du fournisseur devient le modèle du domaine
Des classes générées servent d'entités parce qu'elles étaient déjà là, et le modèle du fournisseur devient discrètement celui du système.
Un changement de licence ou d'API oblige à réécrire la logique du domaine
Les conditions changent, le fournisseur retire une version, ou un meilleur fournisseur apparaît, et le changement touche chaque module au lieu d'un seul adaptateur.
Une panne distante bloque un traitement sans rapport
Un appel synchrone sans délai d'expiration se trouve sur le chemin critique, et un incident chez le fournisseur devient un incident maison.
Des identifiants externes qui prennent un sens interne par accident
Des règles métier bifurquent selon un code externe ; la version suivante du référentiel réutilise ou scinde le code, et une règle que personne n'a touchée change de comportement.
Du contenu sous licence qui s'échappe
Dans les fixtures, les journaux, les messages d'erreur, les caches, la documentation publique, ou le texte envoyé à un modèle.
Des tests qui dépendent du service réel
La suite ne passe que lorsque le fournisseur est disponible, si bien que la disponibilité du fournisseur devient celle du build.
Vérification
Test unitaire
Réussit quand : Le domaine fonctionne contre un double de test du port.
Preuve de dents : Remplacer le double par un double qui lève l'erreur « indisponible » de l'adaptateur : le domaine produit quand même son enregistrement, marqué comme non enrichi.
Test d'architecture
Réussit quand : Les paquets du domaine n'importent aucun paquet du fournisseur et aucun module adaptateur.
Preuve de dents : Planter l'import du fournisseur dans un module du domaine : la règle échoue.
Test de contrat
Réussit quand : L'adaptateur réel et le double de test passent les mêmes tests de contrat pour le port.
Test d'intégration
Réussit quand : Les délais dépassés et les erreurs de connexion du client réel deviennent l'erreur propre au domaine, et jamais une exception générique qui arrête la chaîne de traitement.
Test d'intégration
Réussit quand : Une nouvelle représentation chez le fournisseur ne change que l'adaptateur, et laisse intacts l'API et les tests du domaine. Une nouvelle version du référentiel change les données de correspondance, et les tests qui fixent les règles du domaine disent si une règle dépendait d'un code qui a bougé.
Preuve manuelle
Réussit quand : Une revue de licence de chaque adaptateur : ce qui peut être stocké, pendant combien de temps, et où cela peut apparaître.
Réalisations alternatives
- Un langage publié ou un modèle canonique partagé par plusieurs contextes délimités, chaque référentiel externe y étant mis en correspondance une seule fois.
- Un service enveloppe autour d'un fournisseur, pour que chaque consommateur rencontre la même interface stable.
- Une copie miroir d'un vocabulaire, là où la licence le permet, pour que les consultations cessent de dépendre de la disponibilité.
- Du code généré au build à partir d'un référentiel, gardé dans le paquet de l'adaptateur et jamais exporté hors de celui-ci.
Limites
- L'isolation ne règle pas les conditions de licence. Elle les rend applicables en un seul endroit.
- La correspondance perd des nuances. Une table de correspondance est une connaissance du domaine et a besoin de sa propre revue.
- Le pattern ne décrit pas comment des éléments de preuve externes influent sur la confiance, ce qui relève de P-2.
Sources
- Python Software Foundation: typing.Protocol and runtime_checkable · documentation du langage · Python 3.14 · Vérifié le 2026-09-11