Distributed Monolith
Ein Distributed Monolith besteht aus getrennt deploybaren Einheiten, deren Änderungen oder Störungen dennoch eng zusammenhängen. Gemeinsame Daten und koordinierte Releases können Prozessgrenzen entwerten.
- Gemeinsamer StatusMehrere Dienste schreiben dieselben Daten.
- Koordinierte ReleasesÄnderungen erzwingen gemeinsame Auslieferung.
- SchreibhoheitKorrektur: ein fachlicher Eigentümer.
Einordnung
Warum das wichtig ist
Getrennte Dienste, die gemeinsam veröffentlicht werden müssen, tragen die Kosten verteilter Systeme ohne deren Autonomie. Netzwerkaufrufe und Koordination kommen hinzu, der Nutzen fehlt. Das konkrete Kopplungsbeispiel zeigt Shared Database.
Dieser Baustein diagnostiziert verteilte Kopplung. Shared Database zeigt einen konkreten Kopplungsweg; Trade-off-Analyse vergleicht mögliche Strukturänderungen.
Auf einen Blick · Verteilt, aber gemeinsam freigegeben
Modulgrenze und verteilte Kopplung
Variante: Bestell- und Versanddienste teilen eine Tabelle und müssen gemeinsam veröffentlicht werden. Eine modulare Monolithstruktur bleibt die Ausgangsvariante des Shops.
So liest du das Bild
- Gemeinsamer Status Zeile „Datenverantwortung“, rechte Spalte: „Mehrere Dienste schreiben denselben Status“.
- Koordinierte Releases Zeile „Änderung“: „Änderung koordiniert mehrere Releases“ in der verteilten Variante.
- Schreibhoheit Zeile „Korrekturrichtung“: „Schreibhoheit zuordnen und Dienste entkoppeln“.
| Kriterium | Modularer Monolith – Baseline | Verteilte Variante mit gemeinsamer Tabelle |
|---|---|---|
| Datenverantwortung | Modul besitzt Status und Schnittstelle | Mehrere Dienste schreiben denselben Status |
| Änderung | Vertrag im Shop gemeinsam versionieren | Änderung koordiniert mehrere Releases |
| Ausfallwirkung | Aufruf innerhalb einer Anwendung | Netzwerkaufruf plus gemeinsamer Speicher |
| Korrekturrichtung | Modulvertrag stärken | Schreibhoheit zuordnen und Dienste entkoppeln |
Nutzen & Grenzen
Hilft, wenn
- Regelmäßig koordinierte Releases für einzelne fachliche Änderungen zeigen enge Kopplung zwischen Diensten.
- Synchrone Ketten und gemeinsame Datenverantwortung verbinden Fehler und Verzögerungen über Prozessgrenzen.
Grenzen
- Ein gemeinsamer Release kann fachlich sinnvoll sein; zählt die Häufigkeit über mehrere Änderungen, nicht der einzelne Fall.
- Asynchrone Nachrichten entkoppeln nur den Zeitpunkt; Datenhoheit und gemeinsame Regeln, etwa bei Shared Database, bleiben Kopplung.
- Der modulare Shop braucht keine Trennung, solange seine Modulgrenzen halten; Architektur-Erosion zeigt, wann sie aufweichen.
In der Praxis
- Änderungs- und Betriebsdaten sammeln. Erfasse Releasekoordination, gemeinsame Datenzugriffe und Fehlerketten über mehrere Vorgänge. Ordne jede Beobachtung einer fachlichen Fähigkeit zu. Das Ergebnis macht wiederkehrende Kopplungsmuster über mehrere Vorgänge hinweg sichtbar.
- Verantwortung und Engpass lokalisieren. Bestimme, welche Komponente eine fachliche Entscheidung und die dazugehörigen Daten kontrollieren sollte. Verfolge synchrone Aufrufketten und ihre Ausfallfolgen. Damit werden mögliche Grenzverschiebungen konkret.
- Änderungspfad erneut bewerten. Wähle eine strukturelle Maßnahme wie Vertragsevolution, Zusammenführung oder isolierte Datenhoheit und beobachte die nächste vergleichbare Änderung. Vergleiche Anzahl koordinierter Einheiten und Ausfallreichweite. Das Ergebnis zeigt, ob Unabhängigkeit tatsächlich gewachsen ist.
Ausführliche Erklärung lesen
Ein Distributed Monolith besteht aus mehreren deploybaren Einheiten, deren Änderungen oder Ausfälle dennoch eng miteinander verbunden sind. Gemeinsame Tabellen, lange synchrone Aufrufketten und regelmäßig koordinierte Releases können die Prozessgrenzen entwerten. Die Diagnose stützt sich auf wiederkehrende Änderungs- und Ausfallpfade und ergänzt Begriffe wie Shared Database und Kopplung.
Die Korrektur beginnt bei fachlicher Verantwortung, Datenhoheit und kompatiblen Verträgen. Eng gekoppelte Teile können zusammengeführt oder ihre Abhängigkeiten gezielt reduziert werden. Eine zusätzliche Nachrichtenverbindung schafft allein keine Unabhängigkeit, wenn gemeinsame Entscheidungen und Schreibpfade bestehen bleiben. Entscheidend ist, ob Teams Änderungen und Störungen innerhalb sinnvoller Grenzen bearbeiten können. Die Verteilung bleibt sinnvoll, wenn sie eine unabhängige Verantwortung trägt. Andernfalls können Zusammenführung oder ein stabilerer Vertrag Netzwerk- und Koordinationsaufwand reduzieren.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was gilt in der verteilten Variante für die Ausfallwirkung?
Lösung mit Begründung ansehen
Sie umfasst einen Netzwerkaufruf plus gemeinsamen Speicher, während im modularen Monolithen der Aufruf innerhalb einer Anwendung bleibt.
AnwendenAuf eine neue Lage übertragen
Bestell- und Versanddienst teilen eine Tabelle und werden immer zusammen ausgerollt. Welchen ersten Schritt gehst du?
Lösung mit Begründung ansehen
Lege fest, welcher Dienst den Status schreibt, und lass den anderen ihn über einen kompatiblen Vertrag nutzen. Danach können beide unabhängig veröffentlicht werden.
BewertenEine Alternative abwägen
Alternativ könnte der Shop zum modularen Monolithen zurückkehren. Welchen Vorteil und welchen Preis hat das?
Lösung mit Begründung ansehen
Der Vorteil ist ein Aufruf innerhalb einer Anwendung mit einem gemeinsamen Release. Der Preis ist, dass die Dienste nicht mehr einzeln bereitgestellt werden können.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler – Microservice Premium (öffnet in neuem Tab)Erklärt den zusätzlichen Aufwand verteilter Dienste und notwendige Modulgrenzen.
- How to break a Monolith into Microservices (öffnet in neuem Tab)Zeigt Entkopplung und schrittweise Extraktion entlang sinnvoller Grenzen.
- Sam Newman – Principles of Microservices (öffnet in neuem Tab)Ordnet unabhängige Bereitstellung, Isolation und Dienstautonomie als Gestaltungsprinzipien ein.