Auf dieser Seite
Architektureigenschaft
COADF P-7 ist vollständig veröffentlicht. Klassifikationssysteme, Terminologiedatenbanken und externe Validierungsdienste leben in Adaptermodulen, als solche gekennzeichnet, außerhalb des Kerndatenmodells. Ein externer Dienst kann die Konfidenz eines Attributs erhöhen; keiner von ihnen kann eine Ausgabe blockieren. Ist ein Dienst nicht verfügbar, erzeugt das System weniger konfidente Nachweise statt gar keiner, ändert sich eine Lizenz, bleibt der Kern unberührt, und lizenzierte Inhalte sind in ihren Metadaten gekennzeichnet und vom offenen Kern getrennt gehalten.
Wie eine externe Antwort die Konfidenz verändert, veröffentlicht COADF nicht, und es wird hier nicht beschrieben. Die Beispiele halten eine externe Antwort und ihren Status fest und tun sonst nichts damit.
Warum sie wichtig ist
Standards und Vokabulare überdauern Produkte, wechseln ihre Versionen nach eigenem Zeitplan, tragen Lizenzbedingungen und werden von Systemen bereitgestellt, die man nicht selbst betreibt. Jeder dieser Punkte ist ein Weg, auf dem die Entscheidung eines anderen zum eigenen Ausfall oder zur eigenen Neuentwicklung wird. Die COADF-Regulierungskarte nennt ECLASS und das IEC Common Data Dictionary als lizenzierte Vokabulare, die so behandelt werden; dieselbe Überlegung gilt für einen Identifier-Resolver, einen Klassifikationsanbieter oder einen externen Validierungsdienst mit eigener Verfügbarkeit.
Die Domäne braucht ihre Antworten. Sie darf sie nicht brauchen, um zu funktionieren, und sie darf nicht anfangen, in deren Begriffen zu denken.
Zulässige Umsetzungsstrategien
- Port und Adapter. Die Domäne definiert die Schnittstelle, die sie braucht, in ihren eigenen Worten; jedes externe System erhält einen Adapter, der sie implementiert.
- Anti-Corruption Layer. Der Adapter übersetzt das externe Modell in das Modell der Domäne und zurück, sodass die externen Konzepte und Namen an der Kante enden.
- Eigene Kennungen. Die Domäne behält für ein Konzept ihre eigene Identität und speichert einen externen Code als zugeordnete Referenz: das Schema, die Version des Schemas, den Code, woher er stammt, wann und ob er lizenziert ist.
- Die Version festschreiben. Ein Code bedeutet nur innerhalb einer Version seines Schemas etwas. Die Version wird mit jeder gespeicherten Referenz festgehalten und mit jeder Abfrage mitgeschickt. Ein neuer Transportweg oder eine neue Darstellung des Anbieters kann im Adapter bleiben; eine neue semantische Version des Standards kann ändern, was Codes bedeuten, und dann muss sich die Zuordnung der Domäne mit ihr ändern.
- Explizite Abwesenheit. Ein nicht verfügbarer Dienst ergibt ein festgehaltenes „nicht verfügbar“, nie einen Standardwert und nie eine blockierte Pipeline. Jeder Aufruf hat ein Timeout, und der kritische Pfad wartet nicht auf eine Anreicherung, ohne die er auskommt.
- Lizenzierte Inhalte kennzeichnen. Jeder gespeicherte Wert aus einer lizenzierten Quelle trägt eine Kennzeichnung, damit Exporte, Logs, Caches und öffentliche Artefakte ihn mechanisch auslassen können.
- Eine Plugin-Grenze, wo Adapter optional sind oder von Dritten geliefert werden: geladen über eine Registry, von der die Domäne nicht abhängt.
In Python kann der Port ein typing.Protocol sein, das von statischen Typprüfern geprüft wird; eine isinstance-Prüfung dagegen zur Laufzeit braucht @runtime_checkable und verifiziert nur, dass die Methoden existieren, nicht ihre Signaturen. Das Verhalten verifiziert der Vertragstest.
Fehlermuster
Jeder Fehler als Ausfall bezeichnet
Ein Timeout, widerrufene Zugangsdaten, eine fehlerhafte Anfrage und eine Antwort in neuer Form werden alle als „nicht verfügbar“ gemeldet. Der Ausfall heilt von selbst; die kaputte Integration wird endlos wiederholt und nie repariert. Mindestens „nicht gefunden“, vorübergehende Nichtverfügbarkeit und eine abgewiesene Integration auseinanderhalten, in den eigenen Begriffen des Adapters, nicht in den Statuscodes des Anbieters.
Externe Klassen sickern in die Domäne
Die Typen des Anbieters erscheinen in Signaturen der Domäne, dann im Datenbankschema, dann in der öffentlichen API.
Das SDK des Anbieters wird zum Domänenmodell
Generierte Klassen werden als Entitäten verwendet, weil sie schon da waren, und das Modell des Anbieters wird stillschweigend zum eigenen.
Eine Lizenz- oder API-Änderung bedeutet, Domänenlogik neu zu schreiben
Die Bedingungen ändern sich, der Anbieter stellt eine Version ein oder ein besserer Anbieter taucht auf, und die Änderung berührt jedes Modul statt eines Adapters.
Ein entfernter Ausfall blockiert unabhängige Verarbeitung
Ein synchroner Aufruf ohne Timeout sitzt im kritischen Pfad, und ein Vorfall beim Anbieter wird zum eigenen Vorfall.
Externe Kennungen erhalten ungewollt eine interne Bedeutung
Geschäftsregeln verzweigen anhand eines externen Codes; die nächste Version des Schemas verwendet den Code wieder oder teilt ihn auf, und eine Regel, die niemand angefasst hat, ändert ihr Verhalten.
Lizenzierte Inhalte gelangen nach außen
In Fixtures, Logs, Fehlermeldungen, Caches, öffentliche Dokumentation oder den Text, der an ein Modell geschickt wird.
Tests hängen vom Live-Dienst ab
Die Testsuite besteht nur, wenn der Anbieter erreichbar ist, und so wird die Verfügbarkeit des Anbieters zur Verfügbarkeit des eigenen Builds.
Verifikation
Unit-Test
Bestanden, wenn: Die Domäne funktioniert gegen ein Test-Double des Ports.
Zahnbeweis: Das Double durch eines ersetzen, das den Fehler „nicht verfügbar“ des Adapters auslöst: Die Domäne erzeugt weiterhin ihren Datensatz, als nicht angereichert gekennzeichnet.
Architekturtest
Bestanden, wenn: Domänenpakete importieren kein Paket des Anbieters und kein Adaptermodul.
Zahnbeweis: Den Import des Anbieters in ein Domänenmodul einbauen: Die Regel schlägt fehl.
Vertragstest
Bestanden, wenn: Der echte Adapter und das Test-Double bestehen dieselben Vertragstests für den Port.
Integrationstest
Bestanden, wenn: Timeouts und Verbindungsfehler des echten Clients werden zum eigenen Fehler der Domäne und nie zu einer generischen Ausnahme, die die Pipeline stoppt.
Integrationstest
Bestanden, wenn: Eine neue Darstellung des Anbieters ändert nur den Adapter und lässt die API und die Tests der Domäne unberührt. Eine neue Version des Schemas ändert die Zuordnungsdaten, und die Tests, die die Regeln der Domäne festschreiben, zeigen, ob eine Regel von einem Code abhing, der sich verschoben hat.
Manueller Nachweis
Bestanden, wenn: Eine Lizenzprüfung jedes Adapters: was gespeichert werden darf, wie lange und wo es erscheinen darf.
Alternative Umsetzungen
- Eine Published Language oder ein kanonisches Modell, das mehrere Bounded Contexts teilen, wobei jedes externe Schema einmal darauf abgebildet wird.
- Ein Wrapper-Dienst um einen Anbieter, sodass jeder Konsument auf dieselbe stabile Schnittstelle trifft.
- Eine gespiegelte Kopie eines Vokabulars, wo die Lizenz das erlaubt, sodass Abfragen nicht mehr von der Verfügbarkeit abhängen.
- Zur Build-Zeit generierter Code aus einem Schema, gehalten im Adapterpaket und nie daraus exportiert.
Grenzen
- Isolierung klärt keine Lizenzbedingungen. Sie macht sie an einer Stelle durchsetzbar.
- Zuordnung verliert Nuancen. Eine Zuordnungstabelle ist Domänenwissen und braucht eine eigene Prüfung.
- Das Muster beschreibt nicht, wie externe Nachweise die Konfidenz beeinflussen; das gehört zu P-2.
Quellen
- Python Software Foundation: typing.Protocol and runtime_checkable · Sprachdokumentation · Python 3.14 · Geprüft am 2026-09-11