Sofortantwort
Monolith einfach erklärt
Eine Anwendung als einzelne, zusammenhängende Einheit.
- Kurz gesagt
- Gesamte Anwendung in einer Codebasis und einem Deployment
- Typischer Einsatz
- Startups & MVPs, Kleine Teams, Einfache Domains
- Wichtig zu wissen
- Gegenstück zu Microservices – beide haben ihre Berechtigung
Monolith im Überblick
Ein Monolith ist eine Software-Anwendung, bei der alles zusammen in einer Codebasis lebt und als eine Einheit deployed wird. Frontend, Backend, Datenbank-Zugriff – alles in einem Paket.
Monolith vs. Microservices:
Monolith:
┌─────────────────────────────────┐
│ Eine Anwendung │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │User │ │Order│ │Pay- │ │
│ │Modul│ │Modul│ │ment │ │
│ └─────┘ └─────┘ └─────┘ │
│ Eine Datenbank │
└─────────────────────────────────┘
Microservices:
┌─────┐ ┌─────┐ ┌─────┐
│User │ │Order│ │Pay- │
│Svc │ │Svc │ │ment │
│ DB │ │ DB │ │ DB │
└─────┘ └─────┘ └─────┘
↕ ↕ ↕
API GatewayVorteile des Monolithen:
| Vorteil | Erklärung |
|---|---|
| Einfachheit | Eine Codebasis, ein Deployment, ein Debugging |
| Schneller Start | Kein Overhead für Service-Kommunikation |
| Einfaches Testing | Alles in einem Prozess testbar |
| Keine Netzwerk-Latenz | Funktionsaufrufe statt API-Calls |
Nachteile bei Wachstum:
| Nachteil | Erklärung |
|---|---|
| Deployment-Risiko | Kleine Änderung = ganzes System neu deployen |
| Skalierung | Alles oder nichts skalieren |
| Team-Blockaden | Alle arbeiten in derselben Codebasis |
| Tech-Stack-Lock-in | Eine Sprache/Framework für alles |
Technisch betrachtet
Monolith-Struktur
Typische Schichten:
┌─────────────────────────────────┐
│ Presentation Layer │
│ (UI, API Controllers) │
├─────────────────────────────────┤
│ Business Logic Layer │
│ (Services, Use Cases) │
├─────────────────────────────────┤
│ Data Access Layer │
│ (Repositories, ORM) │
├─────────────────────────────────┤
│ Database │
└─────────────────────────────────┘Modular Monolith
Der Kompromiss zwischen Monolith und Microservices:
┌─────────────────────────────────┐
│ Monolith │
│ ┌─────────┐ ┌─────────┐ │
│ │ User │ │ Order │ │
│ │ Module │ │ Module │ │
│ │ ─────── │ │ ─────── │ │
│ │ Public │ │ Public │ │
│ │ API │←→│ API │ │
│ │ ─────── │ │ ─────── │ │
│ │ Private │ │ Private │ │
│ │ Impl │ │ Impl │ │
│ └─────────┘ └─────────┘ │
└─────────────────────────────────┘Regeln:
- Module kommunizieren nur über definierte APIs
- Keine direkten Datenbank-Zugriffe zwischen Modulen
- Klare Ownership pro Modul
- Später einfacher in Microservices extrahierbar
Wann Monolith, wann Microservices?
| Kriterium | Monolith | Microservices |
|---|---|---|
| Team-Größe | < 10 Entwickler | > 20 Entwickler |
| Deployment-Frequenz | Wöchentlich | Täglich/stündlich |
| Skalierung | Gleichmäßig | Unterschiedlich pro Service |
| Domain-Komplexität | Einfach-mittel | Hoch, viele Bounded Contexts |
| Ops-Expertise | Begrenzt | Stark (K8s, Observability) |
Monolith skalieren
Horizontal:
Load Balancer
│
├── Monolith Instance 1
├── Monolith Instance 2
└── Monolith Instance 3
│
Shared DatabaseOptimierungen:
- Caching (Redis)
- Read Replicas für DB
- CDN für statische Assets
- Async Processing (Message Queue)
Migration zu Microservices
Strangler Fig Pattern:
- Neue Features als Services bauen
- Bestehende Features schrittweise extrahieren
- Monolith wird kleiner, bis er verschwindet
Phase 1: Phase 2: Phase 3:
┌────────┐ ┌────────┐ ┌─────┐
│Monolith│ │Mono- │ │Svc A│
│ │ │lith │ └─────┘
│ │ ├────────┤ ┌─────┐
│ │ │ Svc A │ │Svc B│
└────────┘ └────────┘ └─────┘Schritt für Schritt
Einen Monolithen bewusst entwickeln
Ein Monolith ist keine Vorstufe zu Microservices, sondern oft die passende Architektur. Seine Stärke liegt in klaren Grenzen innerhalb einer gemeinsamen Anwendung.
Fachliche Module schneiden
01
Gruppiere Code nach zusammengehörigen Aufgaben statt nach technischen Schichten allein.
Kunden | Bestellungen | Abrechnung | InhalteModulgrenzen erzwingen
02
Definiere erlaubte Abhängigkeiten, öffentliche Schnittstellen und gemeinsame Regeln für jedes Modul.
Modul A → öffentlicher Vertrag → Modul BEinfach bereitstellen und beobachten
03
Ein gemeinsames Deployment vereinfacht Betrieb, braucht aber Tests, Metriken und sichere Rollbacks.
Build → Tests → Release → Monitoring → RollbackEngpässe konkret messen
04
Prüfe, ob Teamkonflikte, Skalierung oder Release-Risiken tatsächlich in einem abgegrenzten Teil entstehen.
Symptom → Messung → betroffener ModulbereichNur gezielt entkoppeln
05
Wenn nötig, wird zuerst ein klarer, stabiler Bereich herausgelöst – nicht die gesamte Anwendung auf einmal.
klarer Kontext → Vertrag → schrittweise Extraktion
Konkretes Beispiel
Beispiel: Plattform für Terminbuchungen
Ein kleines Team entwickelt Buchung, Benachrichtigungen und Verwaltung gemeinsam in einer Anwendung.
Entscheidungsfrage
Braucht das Team für den Start mehrere unabhängige Services – oder vor allem schnell verständliche Abläufe und einfache Releases?
Modularer Monolith
Eine Codebasis mit klaren Modulen für Buchungen, Nutzer und Kommunikation; getrennte Zuständigkeiten im Code, aber ein gemeinsamer Betrieb.
Die beste erste Architektur ist oft die, die das Team sicher ändern, testen und verstehen kann.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Schneller Start: Ein Repository, ein Deployment und direkte Funktionsaufrufe reduzieren Betriebsaufwand.
- Einfache Änderungen: Fachliche Abläufe lassen sich über Modulgrenzen hinweg gut nachverfolgen.
- Gut testbar: Viele Integrationsfälle können ohne verteilte Infrastruktur geprüft werden.
Das solltest du beachten
- Gemeinsamer Release-Radius: Eine Änderung wird normalerweise zusammen mit der Anwendung ausgeliefert.
- Grenzen verwässern leicht: Ohne Moduldisziplin entstehen schnell schwer verständliche Abhängigkeiten.
- Skalierung nicht immer gezielt: Einzelne rechenintensive Bereiche können den gesamten Betrieb beeinflussen.
Vertiefung · für FortgeschritteneModularer Monolith als zusammenhängendes System
Die Anwendung bleibt gemeinsam betrieben, ihre fachlichen Bereiche kommunizieren aber über bewusste interne Verträge.
Eine auslieferbare Anwendung mit klaren fachlichen Modulen.