Monolithische Architektur
Architekturstil, der alle Anwendungsfunktionen in einer einzigen, zusammenhängenden Codebasis bündelt.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Monolith kann zum Entwicklungsklumpen werden
- Skalierung kann teuer und ineffizient werden
- Technische Schulden durch fehlende Modularität
- Innerhalb des Monolithen klare Modulgrenzen und APIs definieren
- Automatisierte End-to-End-Tests zur Absicherung kritischer Flows
- Monitoring und Health-Checks zentral verfügbar machen
I/O & Ressourcen
- Bestehende Codebasis oder neues Monolith-Design
- Infrastruktur für zentrale Deployments
- Team mit vollständigem Produktkontext
- Einheitliche Anwendungseinheit
- Zentrale CI/CD-Pipeline
- Klar definierte Modulgrenzen innerhalb der Codebasis
Beschreibung
Monolithische Architektur beschreibt die Bündelung aller Komponenten einer Anwendung in einer einzigen, zusammenhängenden Codebasis und Laufzeit. Sie erleichtert Entwicklung, Testing und Deployment in kleinen Teams, skaliert aber schwer granular. Die Empfehlung hängt von Teamgröße, Geschäftsanforderungen und Betriebskosten ab.
✔Vorteile
- Einfachere lokale Entwicklung und Debugging
- Geringerer Koordinationsaufwand zwischen Teams
- Konsistente Versionierung und Deployment
✖Limitationen
- Schwierige, feingranulare Skalierung einzelner Funktionen
- Höhere Risiken bei Änderungen durch enge Kopplung
- Längere Build- und Testzeiten bei wachsender Codebasis
Trade-offs
Metriken
- Build-Dauer
Zeit, bis ein vollständiger Build abgeschlossen ist; beeinflusst Feedback-Zyklen.
- Release-Frequenz
Anzahl der Releases pro Zeiteinheit; zeigt Agilität der Auslieferung.
- Medianer Recovery-Zeitraum
Zeit bis zur Wiederherstellung nach Ausfall; misst Verfügbarkeitseinfluss.
Beispiele & Implementierungen
Klassische Monolith-Webanwendung
Ein einzelnes WAR/JAR mit UI, Geschäftslogik und Datenzugriff in einer Codebasis.
On-Premise ERP-System
Großes, zentral betriebenes ERP mit eng gekoppelten Modulen und gemeinsamen Deployments.
Monolith als ersten Schritt vor Microservices
MVP beginnt monolithisch, um schnell Marktfeedback zu bekommen und später gezielt zu zergliedern.
Implementierungsschritte
Analyse der Domänen und Identifikation von Modulen
Einführung konsistenter Build- und Release-Prozesse
Schrittweise Einführung von Schnittstellen und Verträgen
⚠️ Technische Schulden & Engpässe
Tech Debt
- Geteilte Utility-Klassen ohne Versionierung
- Monolithische Datenmodelle ohne klare Ownership
- Fehlende Testabdeckung für Integrationsebenen
Bekannte Engpässe
Beispiele für Missbrauch
- Monolith skaliert unkontrolliert durch Hinzufügen von Features ohne Modularität
- Versuch, mehrere stark unterschiedliche Domänen in einem Monolithen zu betreiben
- Fehlende Tests führen zu instabilen Releases
Typische Fallen
- Überschätzen, wie lange ein Monolith akzeptabel bleibt
- Unterschätzen der operativen Kosten beim Skalieren
- Ignorieren notwendiger Modularisierungsmaßnahmen
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Infrastruktur-Granularität
- • Monolithische Datenmodelle erschweren Isolation
- • Abhängigkeit von gemeinsamen Bibliotheken