Softwaremodernisierung mit DDD und
Strangler Fig Pattern
Die Herausforderung der Systemmodernisierung:
Vom Monolithen zum Service
Im Zuge moderner Architekturparadigmen, insbesondere der zunehmenden Verbreitung serviceorientierter und cloudnativer Ansätze, wächst der Wunsch, diese Systeme zu modernisieren. Ziel ist es, monolithische Anwendungen in kleinere, flexiblere und skalierbare Services zu überführen – in der Hoffnung, Agilität, Wartbarkeit und technologische Zukunftsfähigkeit zu steigern.
Dieses Transformationsversprechen ist jedoch mit Vorsicht zu geniessen: Der Umbau eines bestehenden Systems hin zu einer servicebasierten Architektur ist ein hochkomplexes Vorhaben, das tief in technische, organisatorische und kulturelle Strukturen eingreift. Ohne eine fundierte Analyse, klare Migrationsstrategie und ein realistisches Erwartungsmanagement droht ein sogenannter „zerhackter Monolith“ – ein System, das zwar formal in Services unterteilt ist, in der Praxis jedoch in seiner Komplexität, Fehleranfälligkeit oder Performance schlechter abschneidet als die ursprüngliche Architektur.
Die erfolgreiche Transformation erfordert daher nicht nur technisches Know-how, sondern vor allem Weitblick, disziplinierte Umsetzung und die Bereitschaft, alte Denkmuster zu hinterfragen. Monolithen pauschal zu verteufeln, greift ebenso zu kurz wie die Vorstellung, durch blosse Zerlegung lasse sich automatisch ein modernes Softwaresystem schaffen.
Strategien zur schrittweisen Migration:
Vom Big Bang zum kontrollierten Umbau
Ein kompletter Umbau monolithischer Systeme im „Big Bang“-Ansatz ist in der Regel weder realistisch noch ratsam. Stattdessen hat sich ein schrittweises, fachlich getriebenes Vorgehen bewährt, das auf klaren strategischen Leitlinien beruht. Ein zentraler Ansatz dafür ist Domain-driven Design (DDD).
Man entwickelt Software ausgehend von der fachlichen Domäne, also der realen Welt, in der das System eingesetzt wird, nicht ausgehend von Technik oder Datenbanken.
Statt einfach „Datenstrukturen und Funktionen“ zu modellieren, fragt man zuerst:
„Wie funktioniert das Geschäft eigentlich genau – und wie können wir das in verständliche, strukturierte Softwaremodelle überführen?“
Ziele von Domain Driven Design (DDD)
1. Fachlichkeit in den Mittelpunkt stellen
DDD zielt nicht auf "gute Architektur" um ihrer selbst willen, sondern darauf, die komplexe Geschäftslogik korrekt und verständlich abzubilden.
2. Fach- und Entwicklungsteams enger verzahnen
Durch die ubiquitäre Sprache (eine gemeinsame Sprache aus dem Fachbereich) entsteht ein geteiltes mentales Modell, das im Code reflektiert wird.
3. Strukturierung grosser Systeme
Komplexe Systeme werden in abgegrenzte, kohärente Bereiche (Bounded Contexts) zerlegt, um Verständlichkeit und Autonomie zu fördern.
4. Wandelbare Geschäftsregeln beherrschbar machen
DDD macht es einfacher, Änderungen in der Fachlichkeit nachvollziehbar und sicher im System umzusetzen.
5. Grundlage für technologische Entscheidungen schaffen
DDD liefert die fachliche Struktur, auf der z.B. Services, APIs, Datenmodelle oder UI-Komponenten aufbauen können.
Kernidee
Statt technische Komponenten oder Infrastruktur-Schichten in Services aufzuteilen, wird die Systemlandschaft entlang fachlicher Domänen neu gedacht. Die Grundlage bildet dabei die Definition sogenannter Bounded Contexts; klar abgegrenzter fachlicher Bereiche mit eigener Sprache, Logik und Verantwortlichkeit. Diese dienen als Blueprint für die zukünftige Service- oder Modulstruktur.
Der Bounded Context definiert den Einsatzbereich eines Domänenmodells. Es umfasst die Geschäftslogik für eine bestimmte Fachlichkeit. Ist ein klar abgegrenzter Bereich, in dem eine bestimmte fachliche Bedeutung und ein spezifisches Modell gelten. Innerhalb dieses Bereichs sind die Begriffe, Regeln und Datenstrukturen eindeutig definiert, ausserhalb nicht unbedingt.
Ein Bounded Context ist wie eine Grenze um ein eigenes „Universum“ – mit seiner eigenen Sprache, Regeln und Bedeutung.
Eine Context Map ist eine Visualisierung oder Beschreibung der Beziehungen zwischen Bounded Contexts in einem Gesamtsystem. Sie zeigt:
• Welche Kontexte existieren
• Wie sie voneinander abgegrenzt sind
• Wie sie miteinander kommunizieren
• Welche Arten von Abhängigkeiten bestehen
DDD und Strangler Fig Pattern in der Migration
Warum beide Konzepte zusammengehören
Das Strangler Fig Pattern beschreibt wie ein Monolith schrittweise ersetzt wird, DDD beantwortet entlang welcher Grenzen. Ohne DDD entstehen willkürliche Schnitte; ohne das Strangler Fig Pattern bleibt DDD eine rein konzeptuelle Übung.
Erweitertes Praktisches Vorgehen
1
Domänenanalyse
Identifikation der wichtigsten Geschäftsbereiche und ihrer Wechselwirkungen. Klassifizierung nach Kern-Domain (höchste Priorität für Extraktion), Supporting Domain und Generic Domain, die Reihenfolge der Extraktion folgt direkt aus dieser Klassifikation.
2
Context Mapping
Aufzeichnung der bestehenden Systemabhängigkeiten und ihrer fachlichen Zuordnung. Das Context Mapping liefert gleichzeitig die Grundlage für die Strangler Facade: welche Routen müssen abgefangen werden, und wohin sollen sie künftig zeigen?
3
Strangler Fig Facade einziehen
Vor jeder Extraktion wird eine Routing-Schicht vorgeschaltet. Sie empfängt alle eingehenden Anfragen und leitet sie zunächst vollständig an den Monolithen weiter. Das Risiko ist null, der Monolith läuft unverändert weiter.
4
Modularisierung des Monolithen
Schrittweise Trennung entlang von Bounded Contexts, z. B. durch Refaktorierung interner Schnittstellen. Dabei entsteht häufig ein Anti-Corruption Layer (ACL), der das neue Modell des Service vom Altmodell des Monolithen entkoppelt.
5
Service-Extraktion
Technische Herauslösung einzelner Kontexte als eigenständige Services, priorisiert nach strategischer Bedeutung (volatile Kern-Domains zuerst). Die Facade leitet den betreffenden Traffic nun auf den neuen Service um; der Monolith verliert diesen Verantwortungsbereich.
6
Integration über APIs oder Events
Aufbau einer stabilen Kommunikationsschicht zwischen den Kontexten (REST, Messaging, Events). Mit vollständiger Extraktion aller Bounded Contexts ist die Fassade selbst überflüssig, der Monolith ist „erdrosselt".
Fazit
Die Modernisierung monolithischer Systeme hin zu servicebasierten Architekturen ist kein Selbstläufer, sie verlangt strategisches Denken, technisches Fingerspitzengefühl und vor allem Geduld. Statt sich von idealisierten Architekturversprechen leiten zu lassen, sollten Unternehmen auf bewährte, risikoarme Migrationsstrategien setzen, die Evolution statt Revolution ermöglichen. Nur so kann das Ziel erreicht werden: ein System, das nicht nur modern aussieht, sondern auch langfristig wartbar, skalierbar und wirtschaftlich tragfähig bleibt.
