© Alexmalexra/Shutterstock.com
Architekturpatterns in Modulithen - Teil 1

Ordnung ins Chaos bringen


„Wir haben diesen Legacy-Monolithen, den wollen wir in Microservices aufbrechen“. So einen Satz hört man als Berater in der Softwarebranche oft. Auf die Frage „Warum“ erhält man oft die Antwort „Modularisierung“. Denn es herrscht die weitverbreitete Ansicht, dass Monolithen grundsätzlich aus schlecht strukturiertem Legacy-Code bestehen und sich Monolithen und Modularisierung gegenseitig ausschließen. Dass dem nicht so ist, zeigt die Architekturform der Modulithen. In dieser Artikelserie wird sie beleuchtet und beschrieben, mit welchen Patterns ein Modulith gelingen kann und welche Antipatterns man dabei vermeiden sollte.

Wer in den letzten sieben Jahren Softwarekonferenzen besucht hat, der musste ganz schön Slalom laufen, wenn er dem Thema Microservices [1] aus dem Weg gehen wollte. Aufgrund ihrer vielversprechenden Eigenschaften wurde diese Form der Systemarchitektur stark gehypt und von vielen Entwicklern, Architekten und Firmen als Heilsbringer angesehen. Mit etwas Abstand betrachtet, handelt es sich dabei aber um keine Silver Bullet, sondern nur um eine von vielen Möglichkeiten, ein Softwaresystem zu strukturieren – mit eigenen Vor- und Nachteilen (Abb. 1). Eine Landschaft aus wirklich entkoppelten Microservices zu bauen, die alle Vorteile dieser Architekturform mitnimmt, ist alles andere als trivial, und man ist selbst dann nicht gegen strukturelle Stolperfallen wie Conway’s Law [2] gefeit. Wenn man Microservices ungünstig schneidet und verknüpft, dann besteht genauso die Gefahr, am Ende einen großen Deployment-Monolithen aus Legacy Code zu erhalten.

franke_modulith_1_1.tif_fmt1.jpgAbb. 1: Vier Jahre später …

Den Hype überlebt haben die „guten alten“ Monolithen. Große Deployment-Einheiten mit einer riesigen Codebase, die sich den Ruf von schlechter Wartbarkeit und Erweiterbarkeit eingehandelt haben. Einerseits überlebten sie, weil man einige davon aufgrund gewachsener Komplexität und schlecht auflösbarer Abhängigkeiten nur schwer wieder losbekommt. Andererseits, weil sie in Form der modularen Monolithen – Modulithen – eine Renaissance in der Entwicklercommunity erleben. Modulithen vereinigen einige der Vorteile der Microservices-Architektur, zum Beispiel modulare Struktur mit gekapselten Verantwortlichkeiten und übersichtlichen Abhängigkeiten, während sie auf einige der Nachteile, wie beispielsweise komplexe Infrastruktur und Kommunikations-Overhead, verzichten. Das macht die Modulithen nicht zu einer den Microservices überlegenen Architekturform (Kasten: „Was können Microservice...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang