Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Muster für die Zersetzung von Monolithen
Nachdem Sie sich entschieden haben, einen Monolithen in Ihrem Anwendungsportfolio zu zerlegen, sollten Sie die geeigneten Zerlegungsmuster auswählen und sie in Ihrem Unternehmen einführen.
**Anmerkung**
Sie können mehrere Muster verwenden, um einen Monolithen zu zerlegen. Sie können beispielsweise einen Monolithen nach [Geschäftsfunktionen](decompose-business-capability.md) zerlegen und ihn dann anhand des [Subdomänenmusters](decompose-subdomain.md) weiter aufschlüsseln.
**Topics**
+ [Zerlegen nach Geschäftsfähigkeit](decompose-business-capability.md)
+ [Nach Subdomain zerlegen](decompose-subdomain.md)
+ [Zerlegen nach Transaktionen](decompose-transactions.md)
+ [Service pro Teammuster](service-per-team.md)
+ [Würger-Feigenmuster](strangler-fig.md)
+ [Verzweigung nach Abstraktionsmuster](branch-by-abstraction.md)
# Zerlegen nach Geschäftsfähigkeit
Sie können den Geschäftsprozess oder die Fähigkeiten Ihres Unternehmens nutzen, um einen Monolithen zu zerlegen. Eine *Geschäftsfähigkeit* ist das, was ein Unternehmen tut, um Wert zu generieren (z. B. Vertrieb, Kundenservice oder Marketing). In der Regel verfügt ein Unternehmen über mehrere Geschäftskapazitäten, die je nach Branche oder Branche variieren. Verwenden Sie dieses Muster, wenn Ihr Team ausreichend Einblick in die Geschäftsbereiche Ihres Unternehmens hat und Sie über Fachexperten (SMEs) für jeden Geschäftsbereich verfügen. In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung dieses Musters erläutert.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) |
In der folgenden Abbildung wird ein Versicherungsmonolith auf der Grundlage der Geschäftskapazitäten in vier Microservices unterteilt.
![\[Zerlegung von Monolithen nach Geschäftsfunktionen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-business-capability.png)
# Nach Subdomain zerlegen
Dieses Muster verwendet eine [DDD-Subdomäne (Domain-Driven Design), um Monolithen zu zerlegen](https://en.wikipedia.org/wiki/Domain-driven_design). *Bei diesem Ansatz wird das Domänenmodell der Organisation in separate Subdomänen unterteilt, die als *Kerndomänen* (ein wesentliches Unterscheidungsmerkmal für das Unternehmen), *unterstützend* (möglicherweise geschäftsbezogen, aber kein Unterscheidungsmerkmal) oder generisch (nicht geschäftsspezifisch) bezeichnet werden.* Dieses Muster eignet sich für bestehende monolithische Systeme mit klar definierten Grenzen zwischen Modulen, die sich auf Subdomänen beziehen. Das bedeutet, dass Sie den Monolithen zerlegen können, indem Sie bestehende Module als Microservices neu verpacken, ohne den vorhandenen Code wesentlich umschreiben zu müssen. *Jede Subdomain hat ein Modell, und der Geltungsbereich dieses Modells wird als begrenzter Kontext bezeichnet.* Microservices werden rund um diesen begrenzten Kontext entwickelt. In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung dieses Musters erläutert.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) |
Die folgende Abbildung zeigt, wie ein Versicherungsmonolith in Subdomänen zerlegt werden kann, nachdem er nach Geschäftskapazitäten zerlegt wurde.
![\[Zerlegung von Monolithen nach Subdomänen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)
Die Abbildung zeigt, dass die *Vertriebs* - und *Marketingservices* in kleinere Microservices unterteilt sind. Die *Einkaufs* - und *Reklamationsmodelle* sind wichtige Unterscheidungsmerkmale für den *Vertrieb* und sind in zwei separate Microservices aufgeteilt. *Marketing* *wird durch die Nutzung unterstützender Geschäftsfunktionen wie *Kampagnen, *Analysen* und Berichte* zerlegt.*
# Zerlegen nach Transaktionen
In einem verteilten System muss eine Anwendung in der Regel mehrere Microservices aufrufen, um eine Geschäftstransaktion abzuschließen. Um Latenzprobleme oder zweiphasige Commit-Probleme zu vermeiden, können Sie Ihre Microservices auf der Grundlage von Transaktionen gruppieren. Dieses Muster ist geeignet, wenn Sie Reaktionszeiten für wichtig halten und Ihre verschiedenen Module nach dem Paketieren keinen Monolithen bilden. In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung dieses Musters erläutert.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |
In der folgenden Abbildung ist der Versicherungsmonolith auf der Grundlage von Transaktionen in mehrere Microservices unterteilt.
![\[Zerlegung von Monolithen nach Transaktionen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)
In einem Versicherungssystem wird ein Schadensantrag in der Regel einem Kunden zugeordnet, nachdem er eingereicht wurde. Das bedeutet, dass ein Schadenservice ohne den Microservice eines *Kunden* nicht existieren kann. *Vertrieb* und *Kunden* sind in einem Microservice-Paket zusammengefasst, und eine Geschäftstransaktion erfordert die Abstimmung mit beiden.
# Service pro Teammuster
Anstatt Monolithen nach Geschäftsfunktionen oder Services zu zerlegen, werden sie nach dem Muster „Service pro Team“ in Microservices aufgeteilt, die von einzelnen Teams verwaltet werden. Jedes Team ist für eine Geschäftsfähigkeit verantwortlich und besitzt die Codebasis der Funktion. Das Team entwickelt, testet, implementiert oder skaliert seine Dienste unabhängig und interagiert hauptsächlich mit anderen Teams, um zu verhandeln. APIs Wir empfehlen, dass Sie jeden Microservice einem einzelnen Team zuweisen. Wenn das Team jedoch groß genug ist, könnten mehrere Unterteams separate Microservices innerhalb derselben Teamstruktur besitzen. In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung dieses Musters erläutert.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) |
Die folgende Abbildung zeigt, wie ein Monolith in Mikroservices aufgeteilt werden kann, die von einzelnen Teams verwaltet, gewartet und bereitgestellt werden.
![\[Zerlegung von Monolithen in Mikroservices durch Teams\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)
# Würger-Feigenmuster
Die bisher in diesem Leitfaden erörterten Entwurfsmuster gelten für Zerlegungsanwendungen bei Projekten auf der grünen Wiese. Was ist mit Brownfield-Projekten, die große, monolithische Anwendungen beinhalten? Es wird schwierig sein, die bisherigen Entwurfsmuster auf sie anzuwenden, da es eine große Aufgabe ist, sie in kleinere Teile zu zerlegen, während sie aktiv genutzt werden.
Das [Würgerfeigenmuster](https://martinfowler.com/bliki/StranglerFigApplication.html) ist ein beliebtes Designmuster, das von Martin Fowler eingeführt wurde, der sich von einer bestimmten Feigenart inspirieren ließ, die sich von selbst in den oberen Ästen von Bäumen aussät. Der bestehende Baum dient zunächst als Stützstruktur für die neue Feige. Die Feige legt dann ihre Wurzeln auf den Boden und umhüllt den ursprünglichen Baum allmählich, sodass nur die neue, sich selbst tragende Feige an ihrer Stelle zurückbleibt.
Dieses Muster wird häufig verwendet, um eine monolithische Anwendung schrittweise in Microservices umzuwandeln, indem eine bestimmte Funktionalität durch einen neuen Dienst ersetzt wird. Ziel ist die Koexistenz der alten und der neuen, modernisierten Versionen. Das neue System wird zunächst vom bestehenden System unterstützt und umschließt es. Diese Unterstützung gibt dem neuen System Zeit, zu wachsen und das alte System möglicherweise vollständig zu ersetzen.
Der Übergang von einer monolithischen Anwendung zu Microservices durch Implementierung des Strangler-Fig-Musters besteht aus drei Schritten: transformieren, koexistieren und eliminieren:
+ *Transformieren* — Identifizieren und erstellen Sie modernisierte Komponenten, indem Sie sie entweder parallel zur Legacy-Anwendung portieren oder neu schreiben.
+ *Koexistenz* — Behalten Sie die Monolith-Anwendung für Rollbacks bei. Fangen Sie externe Systemrufe ab, indem Sie einen HTTP-Proxy (z. B. [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) am Rand Ihres Monolithen integrieren und den Datenverkehr auf die modernisierte Version umleiten. Dies hilft Ihnen, Funktionen schrittweise zu implementieren.
+ *Eliminieren* — Die alten Funktionen werden aus dem Monolithen entfernt, da der Datenverkehr vom alten Monolithen zum modernisierten Dienst umgeleitet wird.
In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung des Würgerfeigenmusters erklärt.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) |
Die folgende Abbildung zeigt, wie ein Monolith in Microservices aufgeteilt werden kann, indem das Strangler-Feigen-Muster auf eine Anwendungsarchitektur angewendet wird. Beide Systeme funktionieren parallel, aber Sie werden beginnen, Funktionen außerhalb der Monolith-Codebasis zu verlagern und sie um neue Funktionen zu erweitern. Diese neuen Funktionen bieten Ihnen die Möglichkeit, Microservices so zu gestalten, dass sie Ihren Anforderungen am besten entsprechen. Sie werden weiterhin Funktionen aus dem Monolithen entfernen, bis alles durch Microservices ersetzt ist. An diesem Punkt können Sie die Monolith-Anwendung eliminieren. Der wichtigste Punkt, den es hier zu beachten gilt, ist, dass sowohl der Monolith als auch die Microservices für eine gewisse Zeit zusammenleben werden.
![\[Zerlegung von Monolithen in Mikroservices mithilfe des Würgerfeigenmusters\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)
# Verzweigung nach Abstraktionsmuster
Das Würgerfeigenmuster funktioniert gut, wenn Sie die Rufe am Rand des Monolithen abfangen können. Wenn Sie jedoch Komponenten modernisieren möchten, die tiefer im Stack der Legacy-Anwendungen vorhanden sind und Upstream-Abhängigkeiten aufweisen, empfehlen wir das Branch-by-Abstraktionsmuster. Dieses Muster ermöglicht es Ihnen, Änderungen an der vorhandenen Codebasis vorzunehmen, sodass die modernisierte Version sicher neben der älteren Version koexistieren kann, ohne dass es zu Störungen kommt.
Gehen Sie wie folgt vor, um das Branch-by-Abstraktionsmuster erfolgreich zu verwenden:
1. Identifizieren Sie Monolith-Komponenten mit Upstream-Abhängigkeiten.
1. Erstellen Sie eine Abstraktionsebene, die die Interaktionen zwischen dem zu modernisierenden Code und seinen Clients darstellt.
1. Wenn die Abstraktion eingerichtet ist, ändern Sie die vorhandenen Clients so, dass sie die neue Abstraktion verwenden.
1. Erstellen Sie eine neue Implementierung der Abstraktion mit der überarbeiteten Funktionalität außerhalb des Monolithen.
1. Schalten Sie die Abstraktion auf die neue Implementierung um, wenn Sie bereit sind.
1. Wenn die neue Implementierung den Benutzern alle erforderlichen Funktionen bietet und der Monolith nicht mehr verwendet wird, bereinigen Sie die ältere Implementierung.
Das Muster der Verzweigung nach Abstraktion wird oft mit [Funktionsumschaltungen verwechselt,](http://martinfowler.com/bliki/FeatureToggle.html) mit denen Sie auch schrittweise Änderungen an Ihrem System vornehmen können. Der Unterschied besteht darin, dass das Umschalten von Funktionen dazu dient, die Entwicklung neuer Funktionen zu ermöglichen und dafür zu sorgen, dass diese Funktionen für Benutzer unsichtbar bleiben, wenn das System läuft. Funktionsschalter werden daher bei der Bereitstellung oder Laufzeit verwendet, um auszuwählen, ob eine bestimmte Funktion oder eine Reihe von Funktionen in der Anwendung sichtbar ist. Bei der Branch-by-Abstraktion handelt es sich um eine Entwicklungstechnik, die mit Funktionsumschaltern kombiniert werden kann, um zwischen der alten und der neuen Implementierung zu wechseln.
In der folgenden Tabelle werden die Vor- und Nachteile der Verwendung von Branch-by-Abstraktionsmustern erklärt.
****
| Vorteile | Nachteile |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) |
Die folgende Abbildung zeigt das Muster der Verzweigung nach Abstraktion für eine *Benachrichtigungskomponente* im Versicherungsmonolith. Zunächst wird eine Zusammenfassung oder Schnittstelle für die Benachrichtigungsfunktion erstellt. In kleinen Schritten werden bestehende Clients so geändert, dass sie die neue Abstraktion verwenden. Dazu kann es erforderlich sein, die Codebasis nach Aufrufen zu durchsuchen, die sich auf die *Benachrichtigungskomponente APIs * beziehen. Sie erstellen die neue Implementierung der Benachrichtigungsfunktion als Microservice außerhalb Ihres Monolithen und hosten sie in der modernisierten Architektur. Innerhalb Ihres Monolithen fungiert Ihre neu erstellte Abstraktionsschnittstelle als Vermittler und ruft die neue Implementierung auf. In kleinen Schritten übertragen Sie die Benachrichtigungsfunktion auf die neue Implementierung, die inaktiv bleibt, bis sie vollständig getestet und bereit ist. Wenn die neue Implementierung fertig ist, schalten Sie Ihre Abstraktion um, um sie zu verwenden. Sie sollten einen Umschaltmechanismus verwenden, der leicht umgedreht werden kann (z. B. einen Funktionsumschalter), sodass Sie bei Problemen problemlos zur alten Funktionalität zurückkehren können. Wenn die neue Implementierung anfängt, Ihren Benutzern alle Benachrichtigungsfunktionen zur Verfügung zu stellen und der Monolith nicht mehr verwendet wird, können Sie die ältere Implementierung bereinigen und alle Switching-Feature-Flags entfernen, die Sie möglicherweise implementiert haben
![\[Zerlegung von Monolithen in Mikroservices unter Verwendung des Branch-by-Abstraktionsmusters\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)