Entwurfsmuster der Antikorruptionsschicht

Implementieren Sie eine Fassade oder Adapterschicht zwischen verschiedenen Subsystemen, die nicht die gleiche Semantik aufweisen. Diese Ebene übersetzt Anforderungen, die ein Subsystem an das andere Subsystem sendet. Verwenden Sie dieses Muster, um sicherzustellen, dass Abhängigkeiten von externen Subsystemen den Entwurf einer Anwendung nicht einschränken. Eric Evans beschrieb dieses Muster zunächst in Domain-Driven Design: Die Komplexität im Herzen der Software anzugehen.

Kontext und Problem

Die meisten Anwendungen basieren auf anderen Systemen für einige Daten oder Funktionen. Wenn Sie beispielsweise eine Legacyanwendung zu einem modernen System migrieren, verwendet die Anwendung möglicherweise weiterhin vorhandene Legacyressourcen. Neue Features müssen in der Lage sein, das Legacysystem aufzurufen. Diese Funktion ist besonders wichtig für schrittweise Migrationen, bei denen Sie unterschiedliche Features einer größeren Anwendung im Laufe der Zeit auf ein modernes System verschieben.

Diese älteren Systeme haben häufig Qualitätsprobleme wie verkettete Datenschemas oder veraltete APIs. Die Features und Technologien, die ältere Systeme verwenden, können von moderneren Systemen stark variieren. Um mit dem älteren System zu arbeiten, muss die neue Anwendung möglicherweise veraltete Infrastruktur, Protokolle, Datenmodelle, APIs oder andere Features unterstützen, die Sie sonst nicht in eine moderne Anwendung einfügen würden.

Wenn Sie den Zugriff zwischen neuen und älteren Systemen beibehalten, erzwingen Sie, dass das neue System mindestens einige der APIs des Legacysystems oder andere Semantik einhalten muss. Wenn diese Altfunktionen Qualitätsprobleme aufweisen, beeinträchtigt diese Unterstützung eine ansonsten sauber konzipierte moderne Anwendung.

Ähnliche Probleme können bei jedem externen System auftreten, das Ihr Entwicklungsteam nicht steuert.

Lösung

Isolieren Sie die verschiedenen Subsysteme, indem Sie eine Antibeschädigungsschicht zwischen ihnen platzieren. Diese Ebene übersetzt die Kommunikation zwischen den beiden Systemen. Mit diesem Ansatz können Sie ein System unverändert halten, ohne den Entwurf und den technologischen Ansatz des anderen zu beeinträchtigen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Das Diagramm zeigt eine Anwendung mit zwei Subsystemen. Subsystem A ruft Subsystem B über eine Antibeschädigungsschicht auf. Die Kommunikation zwischen Teilsystem A und der Antibeschädigungsschicht verwendet immer das Datenmodell und die Architektur des Subsystems A. Aufrufe von der Antibeschädigungsschicht bis zum Subsystem B entsprechen dem Datenmodell oder den Methoden dieses Subsystems. Die Antibeschädigungsschicht enthält alle Logik, die für die Übersetzung zwischen den beiden Systemen erforderlich ist. Sie können die Ebene als Komponente innerhalb der Anwendung oder als unabhängiger Dienst implementieren.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Die Antibeschädigungsschicht fügt Latenz für Aufrufe zwischen den beiden Systemen hinzu.

• Die Antikorruptionsschicht bringt einen zusätzlichen Dienst mit sich, den Sie verwalten und warten müssen.

• Überlegen Sie, wie Sie die Antikorruptionsschicht skalieren möchten.

• Überlegen Sie, ob Sie mehr als eine Anti-Korruptionsschicht benötigen. Sie können beispielsweise Funktionen in mehrere Dienste dekompilieren, die unterschiedliche Technologien oder Sprachen verwenden.

• Überlegen Sie, wie Sie die Antibeschädigungsschicht in Bezug auf Ihre anderen Anwendungen oder Dienste verwalten und wie Sie sie in Ihre Überwachungs-, Freigabe- und Konfigurationsprozesse integrieren.

• Stellen Sie sicher, dass Sie Transaktions- und Datenkonsistenz verwalten und überwachen.

• Überlegen Sie, ob die Antibeschädigungsschicht die gesamte Kommunikation zwischen verschiedenen Subsystemen oder nur eine Teilmenge von Features verarbeiten muss.

• Wenn die Antibeschädigungsschicht Teil einer Migrationsstrategie für Anwendungen ist, überlegen Sie, ob sie dauerhaft ist oder ob Sie sie nach der Migration aller Legacyfunktionen zurückziehen möchten.

• Das vorherige Diagramm verwendet unterschiedliche Subsysteme, um dieses Muster zu veranschaulichen, aber Sie können es auch auf andere Dienstarchitekturen anwenden, z. B. die Legacycodeintegration in einer monolithischen Architektur.

• Da die Anti-Corruption Layer zwischen Systemen vermittelt, die möglicherweise unterschiedliche Vertrauensstufen aufweisen, sollten Sie die Validierung und Bereinigung von Eingaben an dieser Schnittstelle in Betracht ziehen.

• Planen Sie die Beobachtbarkeit, einschließlich Korrelations-IDs und strukturierter Protokollierung, um Übersetzungsfehler zu diagnostizieren.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

• Sie planen eine Migration über mehrere Phasen, müssen jedoch die Integration zwischen neuen und älteren Systemen beibehalten.

• Zwei oder mehr Subsysteme weisen unterschiedliche Semantik auf, müssen aber kommunizieren.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Die neuen und älteren Systeme weisen keine signifikanten semantischen Unterschiede auf. In diesem Szenario ist es wichtig, die Antikorruptionsschicht auf die Übersetzungslogik auszurichten. Vermeiden Sie es, Geschäftsregeln oder Orchestrierung in dieser Schicht zu platzieren.

Arbeitslastgestaltung

Bewerten Sie, wie das „Anti-Corruption Layer“-Muster beim Entwurf einer Workload verwendet werden kann, um auf die in den Säulen des Azure Well-Architected Framework behandelten Ziele und Prinzipien einzugehen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Dieses Muster ist konzeptuell und stammt aus dem domänengesteuerten Designsoftwareentwicklungsansatz. Azure Dienste wie Azure API Management oder Azure Functions helfen möglicherweise bei der Protokollverarbeitung und -übersetzung, aber der Kernzweck einer Antibeschädigungsschicht besteht darin, das Domänenmodell zu schützen, keine bestimmte Produktauswahl zu verschreiben.

Im folgenden Beispiel behandelt die API-Verwaltung die externen Gefährdungs- und Protokollbedenken. Azure Functions implementiert die Antibeschädigungsschicht durch Domänenzuordnung zwischen dem neuen System und dem älteren System. Azure Monitor und Application Insights bieten die Observability, die Sie benötigen, um den Erfolg und die Latenz der Übersetzung zwischen den beiden Subsystemen nachzuverfolgen.

Über dieses synchrone Anforderungsantwortmodell hinaus kann die Antibeschädigungsschicht auch einen asynchronen ereignisgesteuerten Ansatz verwenden. Mithilfe von Azure Service Bus, Azure Event Grid oder Azure Event Hubs entkoppelt die Ebene die moderne Domäne von den Durchsatzeinschränkungen des Legacysystems, um die nachrichtenbasierte Übersetzung für hochdurchsatzreiche oder stark entkoppelte Workloads zu ermöglichen.

Nächste Schritte

• Erkunden Sie Clouddesignmuster, mit denen verteilte Transaktionen verwaltet und die Datenkonsistenz beibehalten werden, z. B. das Muster für ausgleichende Transaktion und das verteilte Saga-Transaktionsmuster.

• Da die Antikorruptionsschicht zu einem Single Point of Failure werden kann, sorgen Sie für Resilienz, indem Sie das Wiederholungsmuster, das Circuit-Breaker-Muster, das Schottmuster und das Health-Endpoint-Überwachungsmuster verwenden.

Zugehörige Ressourcen

• Strangler Fig-Muster
• Messaging Bridge-Entwurfsmuster