Orchestrierung
Orchestrierung macht Ablaufwissen und Fortschritt explizit.
- ProzesszustandSpeichert bestätigten Fortschritt und offene Arbeit.
- BefehlFordert genau einen Teilnehmer zu einer lokalen Aktion auf.
- KlärzustandHält unbekannte oder nicht kompensierbare Ergebnisse sichtbar.
Einordnung
Warum das wichtig ist
Ihr Nutzen liegt in sichtbarer Steuerung bei Fehlern und Neustarts.
Die verteilte Saga ist eine hypothetische Variante; aktuell laufen sieben Module gemeinsam mit einer Datenbank.
Wer steuert den nächsten Schritt?
Der aktuelle Shop verarbeitet B-1042 als modularer Monolith mit sieben Modulen und gemeinsamer Datenbank: Bestand reservieren, Zahlung autorisieren, Bestellung bestätigen, Versand beauftragen. Die Visualisierung vergleicht dafür eine hypothetisch verteilte Saga mit zentralen Befehlen und Ereignisreaktionen. Eine Versandablehnung führt zu ausdrücklich entworfenen Fachoperationen: Bestellung stornieren, Autorisierung stornieren und Bestand freigeben.
So liest du das Bild
- Prozesszustand Orchestrator besitzt Reihenfolge und nächsten Übergang
- Befehl Pfeil vom Orchestrator zum zuständigen Fachmodul
- Klärzustand Fehlerpfad mit Stornierung, Freigabe und offenem Zahlungsausgang
Hypothetische Variante Verteilte Saga für Bestellung B-1042
Ablauf läuftB-1042 · Status dieses vereinfachten Lernablaufs
Ein Koordinator besitzt Reihenfolge und Prozesszustand.
Schritt 1 von 4
Bestand reservieren
Bestellung B-1042 über zwei Tassen ist angelegt.
EntscheidungsortOrchestrator bestimmt den nächsten Übergang. Bestellung besitzt Auftrag und Startentscheidung.
Nutzen & Grenzen
Hilft, wenn
- Ablaufreihenfolge und Gesamtstatus müssen zentral sichtbar sein.
- Viele Fehlerpfade oder Kompensationen brauchen eine explizite Steuerung.
- Ein Team verantwortet die Ablaufänderung über mehrere Teilnehmer.
Grenzen
- Der Orchestrator kann zu einem eng gekoppelten Fachmonolithen werden, wenn er Teilnehmerregeln übernimmt.
- Sein Zustand und seine Verfügbarkeit werden Teil jedes koordinierten Ablaufs.
- Zentrale Sichtbarkeit ersetzt keine atomare Transaktion über Teilnehmer.
In der Praxis
- Modelliere Rückgabe, Wareneingang, Erstattungsfreigabe und Auszahlung als dauerhafte Zustände. Zeige, welcher Schritt nach einem Neustart ausgeführt wird.
- Simuliere einen Timeout nach möglicher Erstattungsbuchung. Halte den Ausgang offen, bis eine Statusabfrage oder ein idempotenter Wiederholungsversuch ihn klärt.
- Prüfe, ob zentrale Ablaufübersicht die zusätzliche Laufzeitabhängigkeit rechtfertigt. Definiere Hochverfügbarkeit und Migration des Orchestratorzustands.
Ausführliche Erklärung lesen
Der Orchestrator sendet einen Befehl, wartet auf ein korreliertes Ergebnis und speichert den Übergang dauerhaft. Nach einem Neustart setzt er am offenen Schritt fort statt den Ablauf aus flüchtigem Speicher zu rekonstruieren.
Timeout, unbekanntes Ergebnis und fachliche Ablehnung sind verschiedene Zustände. Kompensation ist eine neue fachliche Aktion und kann selbst scheitern; manuelle Klärung bleibt ein ausdrücklicher Endzustand.
Saga ordnet lokale Transaktionen und Kompensationen. Partielle Ausfälle erklären unbekannte Ergebnisse über Prozessgrenzen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Woran erkennst du den zentralen Ablaufbesitz?
Lösung mit Begründung ansehen
Jeder Übergang startet beim Orchestrator; die Fachmodule entscheiden weiterhin über ihre lokale Aktion.
AnwendenAuf eine neue Lage übertragen
Welche Arbeit entsteht nach der Versandablehnung?
Lösung mit Begründung ansehen
Der Orchestrator stößt Bestellstornierung, Zahlungsstornierung und Bestandsfreigabe als eigene, idempotente Fachoperationen an.
BewertenEine Alternative abwägen
Wann übernimmt der Orchestrator zu viel?
Lösung mit Begründung ansehen
Sobald er Zulässigkeit und Daten der Fachmodule statt Reihenfolge, Korrelation und Prozessstatus entscheidet.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.