Choreografie
Choreografie verteilt Prozessentscheidungen auf reagierende Teilnehmer.
- EreignisBeschreibt eine vergangene fachliche Tatsache.
- KorrelationVerbindet Reaktionen zu einer Prozessinstanz.
- GesamtstatusZeigt Abschluss, Hänger und manuelle Klärung.
Einordnung
Warum das wichtig ist
Autonomie verlangt einen eigenen Nachweis für den vollständigen Gesamtpfad.
Die verteilte Saga ist eine hypothetische Variante; aktuell laufen sieben Module gemeinsam mit einer Datenbank.
Wer reagiert auf welches Ereignis?
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 Ereignisreaktionen und zentralen Befehlen. Eine Versandablehnung löst Kompensationen nur über ausdrücklich entworfene Reaktionen aus: Bestellung stornieren, Autorisierung stornieren und Bestand freigeben.
So liest du das Bild
- Ereignis Benannte Tatsache zwischen veröffentlichendem und reagierendem Modul
- Korrelation Gemeinsame Schrittfolge für Bestellung B-1042
- Gesamtstatus Statusanzeige für Fortschritt, Abschluss und Klärbedarf
Hypothetische Variante Verteilte Saga für Bestellung B-1042
Ablauf läuftB-1042 · Status dieses vereinfachten Lernablaufs
Teilnehmer reagieren auf vergangene Ereignisse.
BestellungAngelegtSchritt 1 von 4
BestellungAngelegt
Bestellung B-1042 über zwei Tassen ist angelegt.
EntscheidungsortBestellung veröffentlicht die Tatsache; Lager besitzt seine Reaktion. Bestellung besitzt Auftrag und Startentscheidung.
Nutzen & Grenzen
Hilft, wenn
- Teilnehmer reagieren autonom auf stabile Ereignisse.
- Neue Reaktionen sollen ohne zentrale Ablaufänderung hinzukommen.
- Gesamtfortschritt lässt sich aus Ereignissen zuverlässig ableiten.
Grenzen
- Lange Ketten und Rückkopplungen machen Verhalten schwer vorhersehbar.
- Ein fehlendes Ereignis kann den Gesamtprozess unsichtbar anhalten.
- Schemaänderungen haben einen verteilten Änderungsradius über alle Abonnenten.
In der Praxis
- Zeichne die Ereigniskette von RückgabeEingetroffen bis ErstattungAbgeschlossen. Ordne jedem Ereignis einen produzierenden und reagierenden Shopbaustein zu.
- Lass ein Zwischenevent aus oder doppelt eintreffen. Prüfe Korrelation, Idempotenz und die Möglichkeit, einen hängenden Gesamtprozess zu erkennen.
- Vergleiche verteilte Reaktionen mit einem expliziten Orchestrator, wenn ein zusätzlicher Erstattungsschritt eingeführt wird. Bewerte Sichtbarkeit und Änderungsradius.
Ausführliche Erklärung lesen
Jeder Teilnehmer reagiert auf ein vergangenes Ereignis, führt eine lokale Entscheidung aus und veröffentlicht sein Ergebnis. Korrelation und Kausalität verbinden die einzelnen Reaktionen zu einer Prozessinstanz.
Autonomie reduziert zentrale Steuerung, erschwert aber die Frage, wo ein Ablauf hängt oder endet. Ein Statusaggregat, verteilte Traces und definierte Abschlussereignisse machen den Gesamtfortschritt prüfbar.
Saga ordnet Kompensation ein. Publish-Subscribe liefert die Verteilung, garantiert aber allein keinen vollständigen Geschäftsablauf.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Woran erkennst du den verteilten Ablaufbesitz?
Lösung mit Begründung ansehen
Jedes Modul veröffentlicht eine vergangene Tatsache; das nächste Modul besitzt seine darauf entworfene Reaktion.
AnwendenAuf eine neue Lage übertragen
Wie entsteht die Kompensation nach der Versandablehnung?
Lösung mit Begründung ansehen
Bestellung, Zahlung und Lager brauchen ausdrückliche Reaktionen für Stornierung und Freigabe sowie Idempotenz pro Ereigniskennung.
BewertenEine Alternative abwägen
Wann wird die verteilte Reaktionskette schwer beherrschbar?
Lösung mit Begründung ansehen
Wenn Fehlerpfade, Abschluss und Änderungsradius nur über viele Teilnehmer hinweg rekonstruiert werden können.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.