1. Beim Überführen von „Legacy“ Monolithen in moderne domänenorientierte Architektur sind Kompromisse, auch nicht optimale, erforderlich.

2. „Brownfield“ ist die Regel, Greenfield stellt die Ausnahme dar. Wird jedoch an einem „Big Ball of Mud“ gearbeitet sind inkrementelle Verbesserungen der Architektur anzustreben.

3. Domain Driven Design ist bei den Entscheidungsträgern häufig noch unbekannt. Argumente für DDD sind:

   ◦ Legacy Software führt zu hoher Fragilität, was wiederum zu hohen Kosten für Änderungen und Releases führt.

   ◦ Es existieren oft zirkuläre Abhängigkeiten.

   ◦ DDD ermöglicht kleine unabhängige und Crossfunktionale Teams.

4. Entscheidend für den Erfolg der Umwandlung des legacy Monolithen und zur Erhaltung der neuen Architektur ist die Einhaltung von Dependency Discipline, damit nicht in kleinen Schritten erneut ein Monolith entsteht.

5. Alle Schritte die zur Umwandlung vorgenommen werden sollten atomar sein. Oberstes Ziel ist die Sicherung des Betriebs. Um dies zu erreichen:

   ◦ Sollten nur atomare Veränderungen vorgenommen werden.

   ◦ Sollten Integrationstests durchgeführt werden (kleinteilige Unittests sind zu Beginn des Prozesses eventuell noch nicht möglich, End-to-End Tests sind aber realistisch)

   ◦ Sollten alle Änderungen Rückwärtskompatibel ausgeführt werden, um den gemeinsamen Betrieb alter und neuer Komponenten zu erlauben (Strangler-Pattern).

   ◦ Sollten schnelle Rollbacks im Fehlerfall durchführbar sein.

6. Zur Migration sind folgende Schritte erforderlich:

   ◦ Anlegen von geeigneter Dokumentation, falls diese nicht vorhanden ist.

   ◦ Abhängigkeitszirkel auflösen, dazu Komponenten in API und Implementierungskomponente aufteilen.

   ◦ Domänenschnitte ziehen. Falls keine fachlichen Kontexte vorliegen diese durch geeignete Maßnahmen (bspw. Interviews) ermitteln.

   ◦ Onion Architektur anlegen, damit der fachliche Kern frei von technologischen Einflüssen bleibt. Dies erlaubt den parallelen Betrieb neuer und alter Komponenten.

   ◦ Seperation of Concerns anwenden, Softwarekomponenten sollten sich innerhalb einer Komponente nur mit einem fachlichen Belang beschäftigen.

   ◦ Einen „Shared Kernel“ anlegen, aus dem dann schrittweise Funktionalität in die neu zu schaffenden Domänen transferiert werden kann.

7. Um den Domänenschnitt durchzuführen stehen folgende Werkzeuge zur Verfügung:

   ◦ Interviews

   ◦ Ansehen welche Komponenten im Monolith gemeinsam geändert werden. Diese Komponenten könnten zusammenhängen.

   ◦ Engmaschige Abhängigkeitsnetze identifizieren, diese können auf eine Domäne hinweisen.

   ◦ Identifizieren welche Mitarbeiter an welchen Bereichen arbeiten.

Für und wieder: Microservices vs. wohlstrukturierter Monolith

a) Komplexität von APIs geringer

b) kein „unzuverlässiges Netzwerk“ erforderlich - common fallacys of networking

c) kleinerer Technologiestack erforderlich

d) Fehlersuche unter Umständen einfacher, bei MS umfangreiches Monitoring erforderlich

e) Wissen kann einfacher als Paket eingekauft werden (fraglich, Vorteil möglicherweise nur gefühlt)

f) Transaktionalität ist einfacher möglich

g) Skalierbarkeit einzelner Komponenten nach Bedarf - auch finanzieller Aspekt

h) viel Opensource Software (Orchestrierung, Betrieb) steht zur Verfügung

i) Architektur tendiert nicht so stark zu Verklumpung - Monoltith: Riskio das die „wohlstrukturiertheit“ verloren geht

j) Unabhängige crossfunktionale Teams können sich um einzelne Teilbereiche kümmern

k) einzelne Komponenten/Teams können unabhängig voneinander Arbeiten/Deployen (bei Monolith schwieriger)

l) organisatorische Gegebenheiten können besser abgebildet werden (entspricht eher der Domäne)

m) Technologieunabhängigkeit erlaubt flexiblere Auswahl von erforderlicher Expertise

n) Risiko das sich legacy Software und Technologie ansammelt, für die später keine Experten mehr zur Verfügung stehen ist geringer

o) Möglichkeit eines kleineren unabhängigeren Datenmodells

(Rechtsklick -> Ziel speichern unter)

Kernaussagen (PDF)