Der modulare Monolith

Definition: ein Deployment, viele Domänen

Ein modularer Monolith ist eine Anwendung, die als eine Einheit gebaut und deployt wird, deren Code aber auf oberster Ebene in Module unterteilt ist, die fachlichen Grenzen folgen: Bestellungen, Zahlungen, Lieferung, Speisekarten. Jedes Modul hat eine kleine, bewusst gestaltete Modul-API, die andere Module nutzen dürfen, einen größeren internen Teil, den niemand von außen anfassen darf, und eigene Daten. Er verbindet die fachliche Partitionierung von Microservices mit der einzigen Deployment-Einheit eines klassischen Monolithen.

Die Idee ist nicht neu. Module mit verborgenen Interna gehen auf David Parnas’ Information Hiding (1972) zurück, und große, gut strukturierte Monolithen hat es immer gegeben. Neu sind der Name und die Aufmerksamkeit. Nach einem Jahrzehnt, in dem viele Organisationen ihre Systeme in Microservices zerlegt und dabei die Kosten der Verteilung entdeckt haben, argumentierten Fachleute wie Simon Brown und Sam Newman, der modulare Monolith sei eine unterschätzte Option und viele Teams wären mit ihm besser bedient als mit einer Menge von Services. Richards und Ford widmen ihm in der zweiten Auflage von Fundamentals of Software Architecture (2025) ein eigenes Kapitel.

Der Unterschied zum Schichtenstil liegt im Schnitt auf oberster Ebene. Eine Schichtenanwendung ist in Präsentation, Geschäftslogik und Persistenz unterteilt, und jede Domäne verteilt sich über alle drei. Ein modularer Monolith ist nach Domänen unterteilt, und jedes Modul kann innen geschichtet sein. Der Unterschied zu Microservices liegt im Deployment: Die Module teilen sich einen Prozess, ein Release und meist einen Datenbankserver, und sie rufen einander im Arbeitsspeicher auf.

Modul-APIs und interner Code

Die mit Abstand wichtigste Regel lautet: Ein Modul wird nur über seine API genutzt. Die API ist die Menge der Funktionen, Data Transfer Objects und Ereignisse, deren Stabilität die Verantwortlichen des Moduls zusagen; alles andere, einschließlich Domänenmodell, Repositories und Datenbanktabellen, ist intern und darf sich jederzeit ändern. In der Praxis ist die API klein: Ein Zahlungsmodul bietet vielleicht authorise_payment, refund, einen Typ PaymentResult und ein Ereignis PaymentCaptured an und verbirgt Dutzende Klassen für Zahlungsanbieter, Wiederholungen, Buchungsjournale und Abstimmung.

Gute Modul-APIs haben einige Eigenschaften gemeinsam. Sie sprechen die Sprache der Domäne (authorise_payment, nicht insert_payment_row). Sie übergeben einfache Daten wie Kennungen und kleine unveränderliche Datensätze statt interner Objekte, damit Aufrufer nicht über ein zurückgegebenes Objekt in die Interna des Moduls greifen können. Sie sind grob genug, dass ein typischer Anwendungsfall ein oder zwei Aufrufe braucht, nicht zwanzig. Und sie sind so entworfen, als könnte eines Tages ein Netzwerk zwischen Aufrufer und Aufgerufenem liegen: keine gemeinsam genutzten veränderlichen Objekte, keine Abhängigkeit von der Datenbanktransaktion des Aufrufers, explizite Fehler. Diese letzte Eigenschaft hält die Option offen, das Modul später herauszulösen.

Innerhalb der Grenze ist alles erlaubt, was das Team des Moduls für nützlich hält: eine Schichtenstruktur, eine hexagonale, ein reichhaltiges Domänenmodell oder einfache Transaction Scripts. Verschiedene Module können sich unterschiedlich entscheiden, weil nichts außerhalb davon abhängt.

# delivery_platform/payments/__init__.py  (the module's public API)
from .api import authorise_payment, refund, PaymentResult
from .events import PaymentCaptured

__all__ = ["authorise_payment", "refund", "PaymentResult", "PaymentCaptured"]

# delivery_platform/ordering/internal/checkout.py
from delivery_platform import payments             # allowed: public API
# from delivery_platform.payments.internal import ledger   # forbidden

def place_order(order, card_token):
    result = payments.authorise_payment(order.id, order.total, card_token)
    if not result.ok:
        raise PaymentDeclined(result.reason)
    order.confirm(result.payment_id)
    events.publish(OrderPlaced(order.id, order.restaurant_id))

Die Grenzen durchsetzen

In einem Monolithen kann technisch jede Klasse jede andere aufrufen, daher halten Grenzen nur, wenn etwas sie durchsetzt. Ohne Durchsetzung bleibt eine unter Termindruck gebaute Abkürzung in die Interna eines anderen Moduls im Review unsichtbar, und ein modularer Monolith verfällt innerhalb von ein, zwei Jahren zu einem Big Ball of Mud. Es gibt mehrere Verteidigungslinien, die man am besten gemeinsam einsetzt.

Sichtbarkeit in der Sprache. Nutzen Sie die stärkste Kapselung, die die Sprache bietet: paketprivate Klassen in Java, internal in Kotlin und C#, die exports des Java Platform Module System, getrennte Build-Module (Maven- oder Gradle-Teilprojekte, .NET-Projekte), deren Abhängigkeiten explizit deklariert werden. Python und Ruby bieten nur Konventionen (einen führenden Unterstrich, ein Unterpaket internal), daher müssen Werkzeuge die Arbeit übernehmen.

Architekturtests. Architekturtests prüfen Abhängigkeiten im Build. ArchUnit (Java) kann sicherstellen, dass keine Klasse außerhalb eines Moduls dessen interne Pakete berührt und dass die Modulabhängigkeiten zyklenfrei sind. import-linter (Python) bietet einen forbidden-Vertrag, der andere Module daran hindern kann, das interne Paket eines Moduls zu importieren, ihnen aber die Nutzung seiner öffentlichen API weiterhin erlaubt, einen layers-Vertrag, dessen Schichten mehrere voneinander unabhängige Geschwister enthalten können, getrennt durch |, womit sich eine Abhängigkeitsrichtung zwischen Modulen prüfen lässt, und einen independence-Vertrag für Pakete, die überhaupt nicht voneinander abhängen dürfen, auch nicht indirekt.

Unterstützung durch Frameworks. Spring Modulith für Spring-Boot-Anwendungen behandelt jedes direkte Unterpaket des Hauptpakets der Anwendung als Modul, das Basispaket des Moduls als dessen API und seine Unterpakete als intern, und bietet eine einzeilige Verifikation (ApplicationModules.of(Application.class).verify()), die fehlschlägt, wenn ein Modul auf die Interna eines anderen Moduls verweist, wenn Modulabhängigkeiten einen Zyklus bilden oder, falls ein Modul seine erlaubten Abhängigkeiten auflistet, wenn es eine nicht aufgeführte nutzt. Es kann außerdem Komponentendiagramme der Module im C4-Stil erzeugen. In der Ruby-Welt analysiert Shopifys quelloffenes Packwerk statisch die Verweise zwischen Paketen, die jeweils durch eine Datei package.yml deklariert sind, und meldet nicht deklarierte Abhängigkeiten.

Datengrenzen. Geben Sie jedem Modul ein eigenes Datenbankschema (oder zumindest eigene, klar mit Präfix versehene Tabellen) und idealerweise einen eigenen Datenbankbenutzer, der nur auf dieses Schema zugreifen kann. Ein Code-Review allein verhindert keinen bequemen JOIN über Modulgrenzen hinweg; Datenbankberechtigungen schon.

[importlinter:contract:payments-internals]
name = Only payments may use payments internals
type = forbidden
source_modules =
    delivery_platform.ordering
    delivery_platform.delivery
    delivery_platform.reporting
forbidden_modules =
    delivery_platform.payments.internal
# going through the public API (which itself uses internals) is fine
allow_indirect_imports = True

[importlinter:contract:module-order]
name = Module dependencies point one way
type = layers
layers =
    delivery_platform.reporting | delivery_platform.notifications
    delivery_platform.delivery
    delivery_platform.ordering | delivery_platform.restaurants
    delivery_platform.payments | delivery_platform.menus | delivery_platform.customers

Datenhoheit innerhalb eines Monolithen

Bei der Datenhoheit scheitern modulare Monolithen am häufigsten. Einen Datenbankserver zu teilen ist in Ordnung; Tabellen zu teilen nicht. Liest das Liefermodul die Tabelle orders direkt, kann das Bestellteam diese Tabelle nicht mehr ändern, ohne sich mit dem Lieferteam abzustimmen, und die beiden Module sind so eng gekoppelt, als wären sie eins. Die Regel ist einfach formuliert: Jede Tabelle hat genau ein besitzendes Modul, nur der Besitzer schreibt sie, und andere Module beziehen die Daten über die API des Besitzers oder aus Ereignissen, die er veröffentlicht.

Die Regel hat Folgen, die Teams bewusst akzeptieren müssen. Ein Bericht, der früher eine einzige SQL-Abfrage über Bestellungen, Zahlungen und Kuriere war, braucht nun entweder Aufrufe an drei Modul-APIs oder ein Lesemodell: ein Reporting-Modul, das Ereignisse der anderen abonniert und eine eigene, denormalisierte, für Abfragen optimierte Kopie hält. Fremdschlüssel über Modulschemas hinweg werden meist entfernt, weil sie das Schema eines Moduls von dem eines anderen abhängig machen würden; die Integrität über Module hinweg sichert stattdessen die Anwendung. Diese Kosten sind real, aber es sind dieselben Kosten, die ein späterer Umstieg auf Services verursachen würde, nur früher und in einem günstigeren Umfeld bezahlt.

Ein Vorteil bleibt, den verteilte Systeme verlieren: Module in einem Prozess können, wenn es wirklich sein muss, eine einzige lokale Datenbanktransaktion teilen. Nutzen Sie das sparsam. Jede solche Nutzung koppelt die Daten der Module im Betrieb und muss rückgängig gemacht werden, falls ein Modul jemals herausgelöst wird.

Kommunikation zwischen Modulen: Aufrufe oder Ereignisse

Module kommunizieren auf zwei Arten, beide im Arbeitsspeicher. Ein prozessinterner Aufruf der API eines anderen Moduls ist einfach, schnell und unmittelbar: Das Bestellmodul ruft payments.authorise_payment auf und erhält sofort das Ergebnis, und eine Exception wird ganz normal weitergereicht. Das erzeugt eine direkte Abhängigkeit vom Aufrufer zum Aufgerufenen, und der Aufrufer kann erst fertig werden, wenn der Aufgerufene fertig ist. Nutzen Sie Aufrufe, wenn der Aufrufer eine Antwort braucht, um weiterzumachen, etwa ob die Zahlung autorisiert wurde.

Ein prozessinternes Ereignis kehrt die Abhängigkeit um. Das Bestellmodul veröffentlicht OrderPlaced und weiß nicht und kümmert sich nicht darum, wer zuhört; Lieferung, Benachrichtigungen und Reporting abonnieren es. Eine neue Reaktion hinzuzufügen heißt, einen Listener hinzuzufügen, ohne das Bestellmodul anzufassen. Nutzen Sie Ereignisse, wenn der Veröffentlichende keine Antwort braucht und wenn mehrere Module auf dieselbe Tatsache reagieren.

Ereignisse bringen Feinheiten mit sich, die Teams ohne Erfahrung damit oft übersehen. Läuft ein Listener innerhalb der Transaktion des Veröffentlichenden, kann ein Fehler im Listener die Bestellung zurückrollen; läuft er nach dem Commit, ist die Bestellung gespeichert, aber die Arbeit des Listeners kann verloren gehen, wenn der Prozess dazwischen abstürzt. Spring Modulith begegnet dem mit einer Event Publication Registry, die jedes Paar aus Ereignis und Listener in derselben Transaktion wie die fachliche Änderung festhält und erst als abgeschlossen markiert, wenn der Listener erfolgreich war, sodass unvollständige erneut versucht werden können; ein selbst gebautes Gegenstück ist die Transactional Outbox, beschrieben in Abschnitt 6.7. Listener sollten außerdem idempotent sein, damit ein wiederholtes Ereignis keinen Schaden anrichtet. Keiner der beiden Stile ist besser; die meisten modularen Monolithen nutzen Aufrufe für Abfragen und Befehle, die eine Antwort brauchen, und Ereignisse für Benachrichtigungen über bereits Geschehenes.

Shopifys modularer Monolith

Shopifys Kernanwendung ist eine der größten Ruby-on-Rails-Codebasen überhaupt, an der über mehr als ein Jahrzehnt mehr als tausend Entwickler gearbeitet haben. In Deconstructing the Monolith (Shopify Engineering, Februar 2019) beschrieb Kirsten Westeinde, warum das Unternehmen sie nicht in Microservices zerlegte, sondern ab 2017 zu einem modularen Monolithen umbaute. Die Probleme waren bekannt: Code für voneinander unabhängige Geschäftsbereiche war verflochten, Änderungen hatten unerwartete Auswirkungen an anderer Stelle, und die Einarbeitung dauerte lange. Microservices wurden erwogen und als mit eigenen Kosten verbunden eingeschätzt (getrennte Pipelines und Infrastruktur, Netzwerklatenz und -ausfälle, schwierigeres Refactoring über Services hinweg), daher entschied sich das Team für Modularität ohne mehrere Deployment-Einheiten.

Der erste Schritt bestand darin, den Code in einer großen automatisierten Änderung vom Standardaufbau von Rails (Models, Views und Controller) in Komponenten umzuordnen, die nach Fachdomänen benannt waren, etwa Bestellungen, Versand, Lagerbestand und Abrechnung. Der nächste war die Isolation: Jede Komponente sollte eine öffentliche API und die alleinige Hoheit über ihre Daten erhalten, und ein internes Werkzeug, Wedge, verfolgte den Fortschritt jeder Komponente, indem es während der Testsuite Aufrufe über Grenzen hinweg aufzeichnete. Ein Update vom September 2020 meldete 37 Komponenten in einem Kernmonolithen von etwa 2,8 Millionen Zeilen Ruby, und im selben Monat veröffentlichte Shopify Packwerk als Open Source, ein Werkzeug zur statischen Analyse, mit dem sich Abhängigkeiten zwischen Paketen deklarieren und prüfen lassen.

Die Geschichte ist lehrreich, weil sie kein einfacher Erfolg ist. Das Update von 2020 hielt fest, dass die ursprünglichen Ideen noch galten, sich aber fast jedes Detail geändert hatte und kaum eine Komponente bereits eine vollständige, starke Grenze hatte. Ein Rückblick auf Packwerk von 2024 berichtete, dass dessen Privacy-Prüfungen entfernt worden waren, dass manche nach Namen statt nach Laufzeitverhalten organisierte Pakete Entwickler in die Irre führten und dass selbst die vollständige Isolation eines Basispakets viele Monate dauerte; Packwerk war zu einem Wächter über zentrale Grenzen geworden statt zum Kern der Strategie. Die Lehre für Architekten: Ein modularer Monolith ist eine Entwicklungsrichtung, die anhaltende Investitionen braucht, und Grenzen nachträglich in eine große bestehende Codebasis einzuziehen ist viel schwerer, als sie von Anfang an zu wahren.

Wann man ihn einsetzt, wann nicht, und Anti-Patterns

Ein modularer Monolith ist eine starke Standardwahl für neue Produkte mit einigermaßen klarer Domäne, für Organisationen mit bis zu einer Handvoll Teams, für Systeme, die starke Konsistenz über Geschäftsbereiche hinweg brauchen, und für Teams mit begrenzter Betriebskapazität. Er ist auch das natürliche Ziel bei der Modernisierung eines verworrenen Monolithen: Grenzen darin einzuziehen ist meist billiger und weniger riskant, als ihn auf einen Schlag in Services zu zerlegen. Weniger geeignet ist er, wenn Teile des Systems wirklich unterschiedliche Qualitätsmerkmale brauchen (ein Strom von Kurierpositionen, der riesige Schreibvolumen aufnehmen muss, und ein Backoffice-Modul mit mäßiger Last), wenn Dutzende Teams viele Male am Tag unabhängig voneinander releasen müssen oder wenn Teile in verschiedenen Sprachen geschrieben sein oder aus Gründen der Datenresidenz an verschiedenen Orten laufen müssen. Diese Anforderungen verlangen getrennte Architekturquanten.

Häufige Anti-Patterns: Module nur dem Namen nach, bei denen die Ordner den Domänen folgen, aber alles alles importiert; die gemeinsame Datenbank als Selbstbedienungsladen, bei der Module ihren eigenen Code behalten, aber gegenseitig ihre Tabellen joinen; die geschwätzige Grenze, eine API, so feingranular, dass ein Anwendungsfall Dutzende Aufrufe braucht, was schmerzhaft wird, falls das Modul jemals herausgelöst wird; der wuchernde Shared Kernel, ein Modul common, das nach und nach Geschäftslogik aufsaugt und jedes Modul an sich koppelt; und Entitätsmodule, ein Schnitt nach Datenentitäten (ein Kundenmodul, ein Bestellmodul, ein Produktmodul, die jeder Anwendungsfall alle zugleich braucht) statt nach fachlichen Fähigkeiten, was Module hervorbringt, die allein nichts tun können.

Die Option offenhalten, Services herauszulösen

Ein modularer Monolith wird mal als Zwischenschritt zu Microservices dargestellt, mal als Ziel. Er kann beides sein, und der Punkt ist, dass sich die Entscheidung bis zum Last Responsible Moment aufschieben lässt. Muss ein Modul später getrennt skalieren oder unabhängig ausgeliefert werden, ist das Herauslösen viel leichter, wenn das Modul bereits eine explizite API hat, seine Daten besitzt und von anderen nur über APIs und Ereignisse abhängt. Die Arbeit wird dann weitgehend mechanisch: eine Netzwerkschnittstelle vor die API setzen, das Schema in eine eigene Datenbank verschieben, prozessinterne Ereignisse durch einen Message Broker ersetzen und jede gemeinsame Transaktion durch eine explizite Saga oder Kompensation ersetzen.

Sam Newman vertritt in Monolith to Microservices (2019) dasselbe Argument: Ein gut modularisierter Monolith ist der beste Ausgangspunkt für eine Zerlegung, weil der schwierige Teil, Grenzen zu finden und durchzusetzen, bereits erledigt ist. Abschnitt 5.8 behandelt die Anzeichen dafür, dass es Zeit zum Herauslösen ist, und Abschnitt 11.6 behandelt Techniken der schrittweisen Migration wie die Strangler Fig.