Modularer Monolith
Ein modularer Monolith besteht aus abgegrenzten Modulen in einer gemeinsam bereitgestellten Anwendung. Modulverträge schützen Verantwortungen innerhalb des Prozesses.
- ModulAbgegrenzte fachliche Verantwortung mit eigenem Vertrag.
- Ein DeploymentAlle Module werden gemeinsam gebaut und ausgeliefert.
- MitteGrenzen wie bei Services, Betrieb wie bei einem Monolithen.
Einordnung
Warum das wichtig ist
Der modulare Monolith ist die Mitte zwischen Big Ball of Mud und Microservices: klare fachliche Grenzen, aber ohne verteilten Betrieb. Wie Grenzen durchgesetzt werden, zeigt der Baustein Modulgrenzen; hier geht es um die Wahl des Stils.
Dieser Baustein erklärt fachliche Module bei gemeinsamer Auslieferung. Für unabhängig betriebene Dienste siehe Microservices.
Auf einen Blick · Module im gemeinsamen Deployment
Derselbe Shop in drei Formen
Der Ausgangsshop liefert Katalog, Warenkorb, Bestellung, Zahlung, Lager, Versand und Rechnung gemeinsam aus. Nur der Zahlungsanbieter liegt außerhalb.
So liest du das Bild
- Modul Die sieben Shop-Module Katalog bis Rechnung, jeweils mit klarer Aufgabe.
- Ein Deployment Die gestrichelte Fläche „1 Deployment“ und die Kennzahl Deployments: 1 statt 7.
- Mitte Beim modularen Monolithen sind Transaktion und Grenzprüfung beide grün markiert.
Sieben Module mit Verträgen in einer gemeinsam ausgelieferten Anwendung.
- Deployments
- 1
- Netzwerkaufrufe im Checkout
- keine
- Bestellung und Reservierung in einer Transaktion
- ja
- Grenzen durchgesetzt durch
- Architekturtest
- Fehler eines Moduls
- trifft den ganzen Prozess
Bestellung reserviert über den Vertrag im Lager und bucht lokal in einer Transaktion. Ein Test meldet unerlaubte Zugriffe sofort.
Werte illustrativ
Nutzen & Grenzen
Hilft, wenn
- Fachlich klar abgegrenzte Bereiche erhalten durch Modulverträge Orientierung und können gemeinsam ausgeliefert werden.
- Lokale Aufrufe und Transaktionen halten Abläufe einfach; klare Datenbesitzgrenzen sichern die Zuständigkeit der Module.
- Eine gemeinsame Auslieferung gibt Teams Raum, Modulgrenzen zu erproben und eigenständige Betriebsverantwortung schrittweise aufzubauen.
Grenzen
- Keine Fehlerisolation: Ein Speicherleck in einem Modul bringt den ganzen Shop zum Stehen.
- Eine Skalierungseinheit: Der Katalog unter Last zwingt alle Module mit hoch; miss den Bedarf je Modul.
- Die Versuchung der gemeinsamen Datenbank: Grenzen erodieren leise, wenn nichts sie prüft. Siehe Modulgrenzen und Datenhoheit.
In der Praxis
- Gib jedem Modul einen klaren fachlichen Zuständigkeitsbereich und halte dessen Daten intern. Der Vertrag soll nur die Fähigkeiten offenlegen, die andere Module tatsächlich benötigen.
- Prüfe Modulabhängigkeiten und Schreibzugriffe automatisiert. Ein fremdes Modul soll Änderungen über den Besitzervertrag anfragen; so bleiben Regeln auch bei gemeinsamer Auslieferung geschützt.
- Miss gemeinsame Release- und Skalierungskosten; eine Laufzeittrennung folgt, sobald unabhängige Veröffentlichungen oder Lastprofile den zusätzlichen Betrieb rechtfertigen. Für fachliche Zuschnitte hilft Bounded Context; Datenbesitz vertieft Datenhoheit.
Ausführliche Erklärung lesen
Ein modularer Monolith hält fachlich abgegrenzte Module in einer gemeinsam gebauten und ausgelieferten Anwendung. Jedes Modul besitzt Regeln, interne Daten und einen Vertrag für erlaubte Zusammenarbeit. Die Anwendung kann auf mehreren Replikaten laufen oder ergänzende Worker enthalten; die gemeinsame Auslieferungseinheit bleibt der zentrale Betriebsrahmen.
Die Grenze entsteht durch Datenbesitz und kontrollierte Modulzugriffe. Gemeinsame Prozesse erlauben direkte lokale Aufrufe und passende lokale Transaktionen. Verträge und automatisierte Abhängigkeitsprüfungen erhalten die Trennung auch dann, wenn alle Module zusammen veröffentlicht werden.
Modulgrenzen benennen die fachlichen Zuständigkeiten innerhalb der Anwendung; Datenhoheit macht verbindlichen Datenbesitz und erlaubte Änderungen sichtbar.
Für diese Form hat sich der Name Modulith eingebürgert. In Java-Anwendungen prüft zum Beispiel Spring Modulith, ob Module nur ihre erlaubten Verträge nutzen. Shopify betreibt nach eigener öffentlicher Darstellung einen modularen Monolithen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Werte nennt das Bild für Deployments und Netzwerkaufrufe im Checkout beim modularen Monolithen?
Lösung mit Begründung ansehen
Ein Deployment und keine Netzwerkaufrufe im Checkout. Bei Microservices stehen dort sieben Deployments und mehrere Aufrufe.
AnwendenAuf eine neue Lage übertragen
Der Katalog bekommt zur Weihnachtszeit viel mehr Last. Was bedeutet das im modularen Monolithen?
Lösung mit Begründung ansehen
Die Anwendung ist eine Skalierungseinheit, also laufen alle Module mit hoch. Miss zuerst, wie viel Last der Katalog verursacht; erst wenn das teuer wird, lohnt eine Abtrennung.
BewertenEine Alternative abwägen
Das Team will die Grenzen vorerst nicht prüfen, weil alles in einem Repo liegt. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: weniger Aufwand am Anfang. Nachteil: Ohne Prüfung erodieren Grenzen leise, bis der Shop zum Big Ball of Mud wird. Empfehlung: einen Architekturtest früh einführen, denn er ist günstig und hält die Option auf spätere Trennung offen.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Microkernel und Plug-ins
Ein Microkernel hält einen kleinen Kern stabil und erweitert ihn über definierte Plug-in-Punkte. Plug-ins können optionale Fähigkeiten wie Versandregeln oder Zahlungsarten ergänzen; Versionierung des Plug-in-Vertrags und Isolation ihrer Fehler bleiben eigene Entwurfsaufgaben. Ein gemeinsamer Prozess oder ein gemeinsames Deployment erzeugt dabei keine automatische Fehler- oder Sicherheitsisolation. Der Stil passt, wenn Erweiterbarkeit durch austauschbare Module ein zentrales Ziel ist.
Zum AusprobierenLege für einen Shop-Kern einen Plug-in-Vertrag für Versandoptionen fest: beschreibe Erweiterungspunkte, unterstützte Vertragsversionen und das Verhalten bei inkompatiblen Plug-ins. Prüfe außerdem, wie ein fehlerhaftes Plug-in isoliert wird und welche Folgen der gemeinsame Prozess tatsächlich zulässt.
Weiterführende Bausteine
Quellen
- Spring Modulith · Fundamentals (öffnet in neuem Tab)Zeigt fachliche Module und überprüfbare Abhängigkeiten in einer Anwendung.
- Martin Fowler · Monolith First (öffnet in neuem Tab)Erklärt den schrittweisen Weg zu stabilen Modul- und Servicegrenzen.
- Martin Fowler · Breaking a Monolith into Microservices (öffnet in neuem Tab)Zeigt die Vorbereitung von Servicegrenzen und den schrittweisen Umbau.
- Shopify Engineering · Deconstructing the Monolith (öffnet in neuem Tab)Shopify beschreibt, wie ein großer Monolith in Komponenten mit klaren Grenzen gegliedert wird.
- Mark Richards · Microkernel Architecture (öffnet in neuem Tab)Kernsystem, Plug-in-Module und ihre Verträge als Struktur für Erweiterbarkeit.