Ereignisgesteuerte Architektur — erzeugen, veröffentlichen, konsumieren
Ereignisgesteuerte Architektur, interaktiv dargestellt: Producer, Event Bus, Subscriber und Event Store — und wie die Entkopplung neue Consumer dazukommen lässt, ohne Producer zu ändern.
Ereignisgesteuerte Architektur entkoppelt Systeme, indem sie über Events kommunizieren: Producer veröffentlichen, was geschehen ist, der Bus leitet es an die Subscriber weiter, und ein Event Store bewahrt die Historie.
Ereignisgesteuerte Architektur — erzeugen, veröffentlichen, konsumieren
Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.
So lesen Sie diese Darstellung
- Lesen Sie von links nach rechts: aussenden, veröffentlichen, konsumieren und aufbewahren.
- Die Zeile der Producer zeigt nie auf einen Consumer — jeder Pfeil überquert den Bus, und genau darin wird die Entkopplung sichtbar.
- Der untere Zweig ist der Event Store: Dieselben Events, die in Echtzeit konsumiert werden, werden auch zum erneuten Abspielen und zum Prüfen aufbewahrt.
Erzeugen und veröffentlichen
„Services erzeugen Domain-Events“ ist die ganze Zuständigkeit des Producers — festzuhalten, dass etwas geschehen ist. „Events werden auf dem Bus veröffentlicht“ und „Bus leitet Events an Subscriber weiter“ sind der Schritt des Veröffentlichens: Der Bus nimmt Events an und stellt sie jedem zu, der sie abonniert hat. Der Kommentar am Kasten des Aussendens macht die Regel ausdrücklich — Producer wissen nicht, wer zuhört, und genau das macht das System erweiterbar.
In Echtzeit konsumieren
„Consumer verarbeiten Events asynchron“ ist der rechte Weg: Subscriber reagieren auf jedes Event — ein Lesemodell aktualisieren, eine E-Mail senden, einen Ablauf auslösen — in ihrem eigenen Takt. Wegen dieser asynchronen Verarbeitung bremst ein langsamer Consumer keinen Producer, und deshalb hält die Darstellung beide in getrennten Bahnen.
Die Historie aufbewahren
„Event Store bewahrt die ganze Historie“ hält jedes Event der Reihe nach fest, und „Events erneut abspielen für Audit oder Recovery“ sagt, wofür dieser Nachweis da ist — einen Zustand neu aufbauen, eine Prüffrage beantworten oder einen neuen Consumer aus der Vergangenheit speisen. „Neue Consumer kommen dazu, ohne Producer zu ändern“ ist der Prüfstein dieser Architektur: Weil die Historie vorliegt und der Bus nach Abonnement weiterleitet, ändert ein zusätzlicher Service nichts an den vorgelagerten Teilen.
Wichtige Zusammenhänge und Erkenntnisse
- Ein Event hält fest, was geschehen ist; es ist kein Befehl an jemand Bestimmten.
- Der Bus entkoppelt Producer und Consumer — keiner kennt die Identität oder den Takt des anderen.
- Der Event Store macht die Historie zur führenden Quelle, die sich erneut abspielen lässt.
- Consumer arbeiten asynchron: Ein langsamer Consumer blockiert nie einen Producer.
- Neue Consumer kommen durch ein Abonnement dazu — darauf beruht der ganze Flexibilitätsanspruch dieser Architektur.
Wann Sie diese Darstellung nutzen
- Einem Team, das von Anfrage und Antwort auf Events umsteigt, die Aufteilung in Producer, Bus und Consumer vermitteln.
- Eine neue Integration entwerfen: Der Event Store beantwortet, ob die Historie aufbewahrt werden muss oder ob konsumiert und vergessen wird.
- Ein bestehendes ereignisgesteuertes System auf den klassischen Fehler prüfen — einen Consumer, der in Wahrheit eine synchrone Abhängigkeit ist.
So funktioniert es
Benennen Sie die Beteiligten auf Ihr System um
Ersetzen Sie Producer, Consumer und die Eventnamen durch Ihre echten Services und die Events, die sie veröffentlichen, und ergänzen Sie, was das allgemeine Diagramm auslässt.
Benennen Sie die Topics und ihre Consumer
Vermerken Sie an jedem Event auf dem Bus den Namen des Topics und wer es abonniert, damit die Entkopplung eine dokumentierte Karte ist und keine Behauptung.
Ergänzen Sie die Fehlerzweige
Nehmen Sie auf, was passiert, wenn der Bus ausfällt, ein Consumer mitten im Event abbricht oder ein Event zweimal ankommt — jeweils mit dem Mechanismus für Idempotenz oder Wiederholung, der das auffängt.
Erweitern Sie den Event Store
Ergänzen Sie die Regeln für Aufbewahrung und erneutes Abspielen, die Ihr System tatsächlich nutzt — wie lange die Historie bleibt und welche Zustände daraus neu aufgebaut werden —, damit die Bahn des Stores Ihre Vorgaben abbildet.
Häufig gestellte Fragen
Was ist eine ereignisgesteuerte Architektur?
Es ist ein Architekturstil, bei dem Komponenten kommunizieren, indem sie Events veröffentlichen und abonnieren, statt sich direkt aufzurufen. Ein Service, der etwas anlegt oder ändert, veröffentlicht ein Event, das beschreibt, was geschehen ist; der Bus leitet es an jeden Subscriber weiter, den es angeht; und ein Event Store bewahrt die Historie. Weil Producer ihre Consumer nie benennen, kann das System wachsen, ohne das Bestehende anzufassen.
Was unterscheidet einen Befehl von einem Event?
Ein Befehl ist eine Anweisung an einen bestimmten Empfänger — „diese Bestellung verarbeiten“ — und erwartet ein Ergebnis. Ein Event ist die Aufzeichnung, dass etwas bereits geschehen ist — „Bestellung aufgegeben“ — und benennt keinen Empfänger. Der Unterschied zählt, weil Befehle den Sender an den Empfänger koppeln, während Events dem Empfänger die Freiheit lassen, sich zu ändern. Die Producer in dieser Darstellung senden ausschließlich Events aus, und genau das hält den Bus lose.
Wofür ist der Event Store da?
Der Event Store ist die aufbewahrte Historie des Systems: jedes Event, der Reihe nach, dauerhaft. Er dient drei Zwecken — dem Audit (was wann geschah), der Recovery (den Zustand eines Service durch erneutes Abspielen seiner Events wieder aufbauen) und der Erweiterbarkeit (ein neuer Consumer holt auf, indem er die Vergangenheit liest). Die Darstellung zeichnet ihn als unteren Zweig, weil er eine eigene Verwendung derselben Events ist, die Consumer in Echtzeit verarbeiten.
Welche Fehlerfälle hat eine ereignisgesteuerte Architektur?
Die klassischen sind: Events, die mehr als einmal zugestellt werden (Consumer müssen also idempotent sein), Events, die außer der Reihe verarbeitet werden (Consumer müssen also mit der Reihenfolge umgehen), und die Dead Letter Queue (Events, die wiederholt scheitern). Die asynchrone Verarbeitung in der Darstellung ist es, die das beherrschbar macht — ein Consumer kann es erneut versuchen, ohne den Producer zu blockieren —, und deshalb sind die Fehlerzweige in den Schritten die praktische Hälfte des Entwurfs.
Diese Darstellung in QueryChart (FlowJam) bearbeiten
Öffnen Sie genau diese ereignisgesteuerte Zeichenfläche als eigenes Diagramm, benennen Sie Producer und Consumer auf Ihre Services um und zeichnen Sie Ihre Events ein.