Ein Monolith in der Cloud:
Wie wird die Migration zum Erfolg?

Zweiter Teil des Artikels aus VVBmagazin 1/23
von Rudolf Dodel
Domain-Driven-Design

Die Methode Domain-Driven-Design (DDD) von Eric Evans eignet sich, um die fachliche Domäne innerhalb eines Migrationsprojekts detailliert zu analysieren. Mit dieser Methode lassen sich der richtige fachliche und technische Schnitt zwischen den Microservices erreichen sowie deren Abhängigkeiten minimieren.

Dafür unterteilen wir die Domäne in mehrere Subdomänen, die sich wiederum in ein oder mehrere Bounded-Contexts abgrenzen. Ein Bounded-Context hat die Verantwortung über genau eine Fachlichkeit in seiner jeweiliger Subdomäne. Zum Beispiel wären in der Subdomäne „Verkauf“ einer Domäne „Kfz-Versicherung“ „Tarifierung“ oder „Antrag“ denkbare Bounded-Contexts. Parallel hierzu müssen die Beziehungen zwischen den Bounded-Contexts betrachtet werden, um den richtigen Grad der gegenseitigen Kopplung auszuwählen. Hier wird entschieden, ob eine enge oder eine lose Kopplung erreicht werden soll.

Die Abbildung zeigt beispielhaft eine Domäne, bestehend aus zwei Subdomänen „Verkauf“ und „Vertrag“. Diese Subdomänen verfügen jeweils über mehrere Bounded Context und Beziehungen untereinander.

Je stärker die Kopplung, umso höher ist die Abhängigkeit vom verbundenen Bounded-Context. Die Flexibilität reduziert sich mit einer hohen Abhängigkeit. Anhand der Bounded-Contexts bauen wir dann die Microservice-Architektur auf, wobei sich in jedem Microservice mindestens ein Bounded-Context wiederfindet. Ebenso sollte sich ein Bounded-Context nie über mehrere Microservices verteilen, da dies eine nicht gewünschte Abhängigkeit ergibt.

Ein Team ist jeweils für ein oder mehrere der neu erschaffenen Bounded-Contexts verantwortlich. Es sollte dabei nie mehr als ein Team für einen Bounded-Context zuständig sein, da sonst unerwünschte Abhängigkeiten entstehen. Aus diesem Grund müssen wir die Teams analog den Microservices aufteilen.

Event-Storming

Doch wie finden wir die Bounded-Contexts einer Domäne? Dafür eignet sich Event-Storming. Bei dieser Methode beschreibt ein Team aus Entwicklerinnen und Entwicklern und Business-Expertinnen und -Experten die Domäne in Form von fachlichen Ereignissen (Events) und den zugehörigen Auslösern (Commands). Während des Event-Storming-Workshops bilden sich auf dem Board Anhäufungen von Events, die sehr eng beieinander liegen. Diese sind gute Kandidaten für Bounded-Contexts, da diese fachlich zusammengehören und eine starke Kopplung untereinander vorweisen. Gleichzeitig entsteht ein gemeinsames fachliches Domänenmodell, mit dem die technische Umsetzung startet. So wird im Team gemeinsam die Domäne bzw. Subdomäne kontinuierlich erlernt und immer weiter verfeinert.

Das gemeinsam erstellte Domänenmodell ist dabei die Grundlage für die Zielarchitektur. Sobald wir ein erstes Modell für die Domäne (Subdomäne) und deren Bounded-Contexts gefunden haben, bilden wir die Struktur des Monolithen auf den einzelnen Bounded-Contexts ab. Wir bringen somit die Ist- mit der Zielarchitektur zusammen und identifizieren Abweichungen und Maßnahmen für die Migration.

Agilität

Agile Methoden wie Scrum oder Kanban sind mittlerweile schon fast selbstverständlich geworden. Auch bei Migrationsprojekten empfiehlt es sich, darauf zu setzen. Denn es gibt Synergien zwischen agilen Methoden, DDD und der angestrebten Microservice-Architektur. Wird die DDD-Methode eingesetzt, müssen wir in der Lage sein, kontinuierlich zu lernen. Ein klassisches Vorgehensmodell nach Wasserfall-Strukturen würde diesen Lernprozess erheblich behindern.

Mit Agilität, DDD und Event-Storming fokussieren wir uns ausschließlich auf die Fachlichkeit einer Applikation, was ein klarer Benefit ist. Die Technik tritt hierbei komplett in den Hintergrund. Mithilfe dieser Methoden kommen wir dem Ziel näher, ein Optimum für den Cloud-Einsatz für eine bestehende, monolithische Applikation zu erreichen. Die Vorteile der Cloud lassen sich so am besten nutzen (vgl. Artikel 1, VVBmagazin 1/23). So lässt sich für jeden Microservice eine individuelle Betriebsumgebung wählen, um Skalierung, Verfügbarkeit und Kosten optimal zu gestalten.

1) Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (Boston: Addison-Wesley, 2004).
2) Brandolini A., Introducing Eventstorming

Rudolf Dodel ist Lead IT-Consultant bei msg. Er verfügt über mehrjährige Erfahrung als Softwarearchitekt bzw. Softwareengineer in verschiedenen Branchen. Seine Themenschwerpunkte setzt er auf moderne Softwarearchitektur und Cloud.

Dieser Inhalt ist nur für VVB-Mitglieder zugänglich. Bitte melden Sie sich an.
Sie sind noch kein Mitglied? Dann registrieren Sie sich jetzt!

Login zum internen Bereich

Sie möchten weiterlesen? Melden Sie sich jetzt an!

Anmelden