Muster „Antibeschädigungsebene“
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 das Design einer Anwendung nicht durch Abhängigkeiten von externen Subsystemen beschränkt ist. Dieses Muster wurde zuerst von Eric Evans in Domain-Driven Design beschrieben.
Kontext und Problem
Die meisten Anwendungen basieren auf anderen Systemen für einige Daten oder Funktionen. Wenn beispielsweise eine Legacyanwendung zu einem modernen System migriert wird, benötigt sie möglicherweise noch vorhandene Legacyressourcen. Neue Features müssen in der Lage sein, das Legacysystem aufzurufen. Dies gilt insbesondere für graduelle Migrationen, bei denen verschiedene Features einer größeren Anwendung im Laufe der Zeit in ein modernes System verschoben werden.
Häufig leiden diese älteren Systeme an Qualitätsproblemen wie verketteten Datenschemas oder veralteten APIs. Die Features und Technologien, die in älteren Systemen verwendet werden, 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.
Durch die Aufrechterhaltung des Zugriffs zwischen neuen und älteren Systemen kann das neue System dazu zwingen, mindestens einige der APIs des älteren Systems oder andere Semantik einzuhalten. Wenn diese Legacyfeatures Qualitätsprobleme haben, ist die Unterstützung "beschädigt", was andernfalls eine sauber gestaltete moderne Anwendung sein könnte.
Ähnliche Probleme können bei jedem externen System auftreten, das Ihr Entwicklungsteam nicht kontrolliert, nicht nur bei älteren Systemen.
Lösung
Isolieren Sie die verschiedenen Subsysteme, indem Sie eine Antibeschädigungsschicht zwischen ihnen platzieren. Diese Ebene übersetzt die Kommunikation zwischen den beiden Systemen, sodass ein System unverändert bleibt, während der andere den Entwurf und den technologischen Ansatz nicht beeinträchtigen kann.
Das obige Diagramm zeigt eine Anwendung mit zwei Subsystemen. Subsystem A-Aufrufe des Subsystems B über eine Antibeschädigungsschicht. 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. Die Ebene kann als Komponente innerhalb der Anwendung oder als unabhängiger Dienst implementiert werden.
Probleme und Überlegungen
- Die Antibeschädigungsschicht kann Latenz für Aufrufe zwischen den beiden Systemen hinzufügen.
- Die Antibeschädigungsschicht fügt einen zusätzlichen Dienst hinzu, der verwaltet und verwaltet werden muss.
- Überlegen Sie, wie Ihre Antibeschädigungsschicht skaliert wird.
- Überlegen Sie, ob Sie mehr als eine Antibeschädigungsschicht benötigen. Möglicherweise möchten Sie die Funktionalität in mehrere Dienste unter Verwendung verschiedener Technologien oder Sprachen dekompilieren, oder es gibt andere Gründe, die Antibeschädigungsschicht zu partitionieren.
- Überlegen Sie, wie die Antibeschädigungsschicht in Bezug auf Ihre anderen Anwendungen oder Dienste verwaltet wird. Wie wird es in Ihre Überwachungs-, Release- und Konfigurationsprozesse integriert?
- Stellen Sie sicher, dass Transaktions- und Datenkonsistenz beibehalten werden und überwacht werden können.
- Ü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 nach der Migration aller Legacyfunktionen eingestellt wird.
- Dieses Muster wird mit unterschiedlichen Subsystemen oben veranschaulicht, kann aber auch auf andere Dienstarchitekturen angewendet werden, z. B. wenn Legacycode in eine monolithische Architektur integriert wird.
Wann dieses Muster verwendet werden soll
Verwenden Sie dieses Muster in folgenden Fällen:
- Es ist geplant, dass eine Migration über mehrere Phasen erfolgt, die Integration zwischen neuen und älteren Systemen muss jedoch beibehalten werden.
- Zwei oder mehr Subsysteme weisen unterschiedliche Semantik auf, müssen aber dennoch kommunizieren.
Dieses Muster eignet sich möglicherweise nicht, wenn es keine signifikanten semantischen Unterschiede zwischen neuen und älteren Systemen gibt.
Workloadentwurf
Ein Architekt sollte bewerten, wie das Muster der Antibeschädigungsschicht im Entwurf ihrer Workload verwendet werden kann, um die Ziele und Prinzipien zu erfüllen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Beispiel:
| Säule | So unterstützt dieses Muster die Säulenziele |
|---|---|
| Operational Excellence hilft, Arbeitsauslastungsqualität durch standardisierte Prozesse und Teamzusammenhalt zu liefern. | Mit diesem Muster wird sichergestellt, dass das design neuer Komponenten nicht mehr von älteren Implementierungen abhängig ist, die möglicherweise unterschiedliche Datenmodelle oder Geschäftsregeln aufweisen, wenn Sie diese legacy-Systeme integrieren und die technische Verschuldung in neuen Komponenten reduzieren und gleichzeitig vorhandene Komponenten unterstützen. - OE:04 Tools und Prozesse |
Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.