Modular Monolith
Einleitung
Der Modular Monolith ist kein „Monolith mit besserem Marketing“,
sondern eine bewusste Architekturstrategie.
Er verbindet:
- die Einfachheit eines einzelnen Deployables
- mit der Strukturierung in klar abgegrenzte, domänenorientierte Module
Ziel ist:
Schnelle Entwicklung bei kontrollierter Komplexität –
ohne die Kosten verteilter Systeme.
Einordnung
Der Modular Monolith ist ein Makro-Architekturstil auf Systemebene.
Merkmale:
- eine Codebase
- ein Deployable
- interne Modulgrenzen
- domänenorientierte Struktur
Er unterscheidet sich vom „klassischen Monolithen“ durch:
- explizite Boundaries
- technische Durchsetzung von Modulgrenzen
- Domain-First-Schnitt
Grundprinzip
Kernaussage:
- Module kommunizieren nur über definierte APIs
- Keine direkten Implementierungsabhängigkeiten
- Struktur entsteht bewusst – nicht zufällig
Zielsetzung
Der Modular Monolith soll:
- Komplexität reduzieren
- schnelle Lieferfähigkeit ermöglichen
- klare fachliche Boundaries etablieren
- spätere Extraktion ermöglichen
- verteilte Systemkosten vermeiden
Er ist besonders geeignet als:
Evolutionsbasis für wachsende Systeme.
Charakteristika
1️⃣ Domain-orientierte Module
Module sind geschnitten nach:
- Bounded Contexts
- Geschäftsfähigkeiten
- klarer Ownership
Nicht nach technischen Schichten.
2️⃣ Ein Deployable
- Kein verteiltes Deployment
- Kein Netzwerk zwischen Modulen
- Keine verteilten Transaktionen
Skalierung erfolgt:
- vertikal
- oder als Ganzes horizontal
3️⃣ Explizite Modul-APIs
Module:
- exponieren stabile Schnittstellen
- kapseln Implementierungsdetails
- verbieten implizite Querverweise
Ohne technische Enforcement degeneriert der Stil.
4️⃣ Datenstruktur
- Häufig gemeinsame Datenbank
- Logische Ownership je Modul
- Zugriff nur über Modul-API
Risiko:
Shared DB wird zum impliziten Integrationsbus.
5️⃣ Team-Schnitt
Teams können:
- entlang der Module arbeiten
- Feature-Verantwortung übernehmen
- ohne verteilte Ops-Komplexität liefern
Vorteile
- Geringerer Betriebsaufwand
- Höhere Entwicklungs-Geschwindigkeit
- Einfacheres Debugging
- Kein verteiltes Tracing notwendig
- Klare Evolution möglich
- Gute Testbarkeit
Nachteile / typische Fallstricke
1️⃣ Boundary-Erosion
Wenn Modulgrenzen nicht technisch abgesichert sind:
- entstehen implizite Abhängigkeiten
- wird das System zum Legacy-Monolithen
2️⃣ Begrenzte Skalierungsgranularität
Ein einzelnes Modul kann nicht isoliert skaliert werden.
3️⃣ Organisatorische Disziplin notwendig
Architektur lebt von:
- Code-Reviews
- Architekturrichtlinien
- Tooling (Package-Visibility, Module-Systeme)
Modular Monolith vs. Microservices
| Modular Monolith | Microservices | |
|---|---|---|
| Deployment | 1 | viele |
| Ops-Komplexität | gering | hoch |
| Debugging | einfach | verteilt |
| Skalierung | gesamtes System | granular |
| Startkosten | niedrig | hoch |
| Evolutionsfähigkeit | hoch | hoch (bei Reife) |
Viele erfolgreiche Microservice-Systeme starteten als Modular Monolith.
Eignung 2026
Passt gut, wenn:
- Greenfield-Projekt
- Schnelles Lernen wichtiger als extreme Skalierung
- Team klein bis mittelgroß
- Domänen klar schneidbar
- Plattform-Reife noch nicht hoch
Weniger geeignet, wenn:
- extreme, unabhängige Skalierung erforderlich ist
- Multi-Region-Isolation zwingend ist
- sehr unterschiedliche Compliance-Grenzen existieren
Evolutionspfad
Ein typischer Weg:
- Modular Monolith
- Stabilisierung von Boundaries
- Identifikation heißer Module
- Extraktion einzelner Module als SCS oder Microservices
Nicht:
„Wir starten direkt mit 40 Services.“
Praxis-Check
Szenario 1: SaaS im Wachstum
Start als modularer Monolith. Spätere Extraktion einzelner Domänen bei Last- oder Organisationswachstum.
Szenario 2: Stark reguliertes System
Wenn harte Isolation oder getrennte Compliance-Zonen nötig sind, kann eine verteilte Architektur erforderlich werden.
Fazit
Der Modular Monolith ist keine Übergangslösung. Er ist oft die strategisch richtige Startarchitektur.
Er maximiert:
- Geschwindigkeit
- Klarheit
- Änderbarkeit
bei minimaler operativer Komplexität.
Verteilung sollte eine Reaktion auf Wachstum sein – nicht der Ausgangspunkt.