Von Monolithen in Microservices mit Domain-driven Design (DDD)

In diesem Artikel wird beschrieben, wie Sie das an Fachlichkeiten ausgerichtete Design (Domain-driven Design, DDD) zum Migrieren einer monolithischen Anwendung in Microservices einsetzen.

Eine monolithische Anwendung ist in der Regel ein Anwendungssystem, in dem alle relevanten Module als eine bereitzustellende Ausführungseinheit zusammen gepackt sind. Dies kann beispielsweise eine Java-Webanwendung (WAR) sein, die unter Tomcat ausgeführt wird, oder eine ASP.NET-Anwendung unter IIS. Für eine typische monolithische Anwendung wird ein Schichtenmodell mit separaten Schichten für Benutzeroberfläche, Anwendungslogik und Datenzugriff verwendet.

Diese Systeme sind zu Beginn recht klein und wachsen im Allgemeinen im Laufe der Zeit, um die geschäftlichen Anforderungen zu erfüllen. Ab einem gewissen Punkt können bei einer monolitischen Anwendung beim Hinzufügen neuer Funktionen die folgenden Probleme auftreten:

Die einzelnen Teile des System können nicht unabhängig voneinander skaliert werden, da sie eng miteinander gekoppelt sind.
Die Pflege des Codes gestaltet sich aufgrund der engen Kopplung und versteckter Abhängigkeiten schwierig.
Tests werden schwieriger, was die Wahrscheinlichkeit von eingeschleusten Sicherheitsrisiken erhöht.

Diese Probleme können sich als Hindernis für zukünftiges Wachstum und Stabilität erweisen. Teams hüten sich zunehmend davor, Änderungen vorzunehmen, besonders wenn der ursprüngliche Entwickler nicht mehr am Projekt mitarbeitet und die Entwurfsdokumentation entweder dürftig oder veraltet ist.

Trotz dieser Einschränkungen kann ein monolithischer Entwurf als Ausgangspunkt für eine Anwendung Sinn machen. Monolithen stellen häufig den schnellsten Weg zum Erstellen einer Machbarkeitsstudie (Proof-of-Concept) oder eines Produkts mit minimalen Anforderungen und Eigenschaften (Minimum Viable Product) dar. In den frühen Entwicklungsphasen weisen Monolithen im Allgemeinen folgende Vorteile auf:

Sie sind leichter zu erstellen, da es nur eine gemeinsame Codebasis gibt.
Sie sind einfacher zu debuggen, da der Code in einem einzelnen Prozess und einem Speicherbereich ausgeführt wird.
Die Begründung wird vereinfacht, da es weniger Variablen gibt.

Mit zunehmender Komplexität der Anwendung können sich diese Vorteile jedoch auflösen. Häufig sind große Monolithen immer schwieriger zu erstellen, zu debuggen und zu begründen. Ab einem gewissen Punkt überwiegen die Probleme die Vorteile. An diesem Punkt kann es sinnvoll sein, die Anwendung zu einer Microservices-Architektur zu migrieren. Im Gegensatz zu Monolithen sind Microservices in der Regel dezentrale, lose miteinander verbundene Ausführungseinheiten. Aus dem folgenden Diagramm geht die typische Microservices-Architektur hervor:

Die Migration eines Monolithen in einen Microservice erfordert einen erheblichen Zeit- und Kostenaufwand, um Fehler oder Kostenüberschreitungen zu vermeiden. Um eine erfolgreiche Migration zu gewährleisten, ist es wichtig, sowohl die Vorteile als auch die Herausforderungen zu kennen, die Microservices mit sich bringen. Es ergeben sich folgende Vorteile:

Die Dienste können unabhängig voneinander und aufgrund von Benutzerbedarf entwickelt werden.
Die Dienste können unabhängig skaliert werden, um den Benutzerbedarf zu erfüllen.
Mit der Zeit werden die Entwicklungszyklen schneller, da die Features schneller auf den Markt kommen können.
Die Dienste sind isoliert und fehlertoleranter.
Ein einzelner fehlerhafter Dienst verursacht nicht den Ausfall der ganzen Anwendung.
Tests werden durch die Verwendung der verhaltensgetriebenen Softwareentwicklung (Behavior-driven Development, BDD) kohärenter und einheitlicher.

Weitere Informationen zu den Vorteilen und Herausforderungen von Microservices finden Sie unter Microservices-Architektur.

Anwenden von Domain-driven Design

Jede Migrationsstrategie sollte den Teams die Möglichkeit geben, eine schrittweise Refaktorisierung der Anwendung in kleinere Dienste vorzunehmen und gleichzeitig die Dienstkontinuität für die Endbenutzer aufrecht zu erhalten. Die allgemeine Vorgehensweise sieht folgendermaßen aus:

Hören Sie auf, dem Monolithen Funktionalität hinzuzufügen.
Separieren Sie Front-End und Back-End.
Zerlegen und entkoppeln Sie den Monolithen in eine Reihe von Microservices.

Ein praktikabler Softwareentwicklungsansatz zur Vereinfachung des Zerlegevorgangs ist die Anwendung der DDD-Prinzipien (Domain-driven Design).

Domain-driven Design (DDD) ist ein Ansatz zur Entwicklung von Software, der erstmalig von Eric Evans vorgestellt wurde. DDD setzt gute Kenntnisse des Fachbereichs (Domäne) voraus, für den die Anwendung geschrieben wird. Über die Domänenkenntnisse, die zum Erstellen der Anwendung erforderlich sind, verfügen die Personen, die die Domäne kennen: die Domänenexperten.

Der DDD-Ansatz kann rückwirkend auf eine vorhandene Anwendung angewendet werden und als Möglichkeit dienen, mit dem Zerlegen der Anwendung zu beginnen.

Beginnen Sie mit einer ubiquitären Sprache, einem allgemein verwendeten Vokabular, das von allen Beteiligten gemeinsam verwendet wird.
Identifizieren Sie die entsprechenden Module in der monolithischen Anwendung, und wenden Sie das allgemeine Vokabular auf diese an.
Definieren Sie die Domänenmodelle der monolithischen Anwendung. Das Domänenmodell ist ein abstraktes Modell der Geschäftsdomäne.
Definieren Sie Kontextgrenzen für die Modelle. Eine Kontextgrenze bezeichnet den abgegrenzten Bereich innerhalb einer Domäne, in dem ein bestimmtes Domänenmodell gilt. Wenden Sie explizite abgegrenzte Bereiche mit eindeutig definierten Modellen und Verantwortlichkeiten an.

Die in Schritt 4 identifizierten Kontextgrenzen sind die Kandidaten für die Refaktorisierung in kleinere Microservices. Das folgende Diagramm zeigt den vorhandenen Monolithen mit eingeblendeten Kontextgrenzen:

Verwenden von Glue Code (Antikorruptionsschicht)

Während dieser investigativen Arbeit zur Bestandsaufnahme der monolithischen Anwendung können Sie unter Anwendung der DDD-Prinzipien neue Funktionalität als separate Dienste hinzufügen. Der „Glue Code“ gibt der monolithischen Anwendung die Möglichkeit, über einen Proxy den neuen Dienst aufzurufen und die neue Funktionalität abzurufen.

Der Glue Code (Adaptermuster) fungiert gewissermaßen als Antikorruptionsschicht und stellt sicher, dass der neue Dienst nicht durch für die monolithische Anwendung erforderliche Datenmodelle belastet wird. Der Glue Code trägt zur Vermittlung der Interaktion zwischen den beiden bei und stellt sicher, dass nur die Daten, die für den neuen Dienst erforderlich sind, übergeben werden, um Kompatibilität zu ermöglichen.

Durch den Refaktorierungsvorgang können die Teams den Bestand der monolithischen Anwendung erfassen, Kandidaten für die Refaktorierung in Microservices identifizieren und gleichzeitig neue Funktionalität mit neuen Diensten einrichten.

Weitere Informationen zu Antikorruptionsschichten finden Sie unter Muster „Antikorruptionsschicht“.

Erstellen einer Darstellungsschicht

Im nächsten Schritt muss die Darstellungsschicht von der Back-End-Schicht getrennt werden. In einer herkömmlichen Anwendung mit n Ebenen bilden im Allgemeinen die Hauptkomponenten der Anwendung mit der Domänenlogik die Anwendungsschicht (Geschäftsschicht). Diese undifferenzierten APIs interagieren mit der Datenzugriffsschicht, um persistente Daten aus einer Datenbank abzurufen. Die APIs stellen eine natürliche Begrenzung zur Darstellungsschicht her und helfen dabei, diese zu entkoppeln und in einen separaten Anwendungsbereich zu überführen.

Das folgende Diagramm enthält die von der Anwendungslogik und den Datenzugriffsschichten getrennte Darstellungsschicht (Benutzeroberfläche).

In diesem Diagramm wird zudem eine weitere Schicht vorgestellt: der API-Gateway. Diese Schicht befindet sich zwischen der Darstellungsschicht und der Anwendungslogik. Der API-Gateway ist eine Fassadenschicht, die eine konsistente und einheitliche Oberfläche für die Interaktion mit der Darstellungsschicht bereitstellt und gleichzeitig eine eigenständige Entwicklung von Downstreamdiensten – ohne Auswirkungen auf die Anwendung – gestattet. Für den API-Gateway kann eine Technologie wie Azure API Management verwendet werden, die der Anwendung eine Interaktion nach REST-Prinzipien erlaubt.

Die Darstellungsschicht kann in einer beliebigen Sprache oder unter Verwendung eines beliebigen Frameworks entwickelt werden, mit der bzw. dem das Team Erfahrung hat, z. B. Single-Page- oder MVC-Anwendung. Diese Anwendungen interagieren über den Gateway mit den Microservices und verwenden dafür standardmäßige HTTP-Aufrufe. Weitere Informationen zu API-Gateways finden Sie unter Verwenden von API-Gateways in Microservices.

Beginn der Außerbetriebnahme des Monolithen

In diesem Stadium kann das Team damit beginnen, die monolithische Anwendung zu zerlegen und langsam die Dienste zu extrahieren, die anhand ihrer Kontextgrenzen in einem eigenen Satz von Microservices eingerichtet wurden. Die Microservices können eine Oberfläche nach REST-Prinzipien für die Interaktion mit der Anwendungsschicht – über den API-Gateway – aufweisen. Für die Kommunikation mit dem Monolithen in speziellen Fällen sorgt der vorhandene Glue Code.

Beim weiteren Zerlegen des Monoliths kommen Sie letztlich an einen Punkt, wo der Monolith seine Existenzberechtigung verloren hat und die Microservices erfolgreich aus dem Monolithen extrahiert wurden. An dieser Stelle kann die Antikorruptionsschicht (Glue Code) sicher entfernt werden.

Dieser Ansatz dient als Beispiel für das Strangler-Muster und ermöglicht die kontrollierte Zerlegung eines Monolithen in eine Reihe von Microservices. Während die vorhandene Funktionalität in Microservices verschoben wird, nehmen Größe und Komplexität des Monolithen immer weiter ab, bis er nicht mehr vorhanden ist.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Lavan Nallainathan | Senior Cloud Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Wenn die Anwendung in die zugehörigen Microservices zerlegt wurde, können moderne Orchestrierungstools wie Azure DevOps zum Einsatz kommen, um den Lebenszyklus der einzelnen Dienste zu verwalten. Weitere Informationen finden Sie unter CI/CD für Microservices-Architekturen.

Entwerfen von Microservices im Rahmen der taktischen DDD-Phase
Architekturentwurf für Microservices
Bewertung und Bereitschaft von Microservices
Entwurfsmuster für Microservices

Von Monolithen in Microservices mit Domain-driven Design (DDD) - Azure Architecture Center (2024)