Ereignisgesteuerte Architektur · Mindmaps
Ereignisgesteuerte Architektur. Eine bearbeitbare Mindmap mit farbigen Zweigen, Unterthemen und Verbindungen. Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.
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 · Mindmaps
Die interaktive MindMap-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 Mindmap
- Beginnen Sie beim Thema in der Mitte und folgen Sie einem farbigen Zweig zu den zugehörigen Ideen.
- Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.
Producers
Dieser Zweig verbindet “An event records something that HAPPENED — “order placed”, “user updated” — not an instruction to anyone in particular. Producers don't know who is listening.”.
Event bus
Dieser Zweig verbindet “Events are published to the bus”, “The bus decouples producers from consumers: a producer keeps publishing whether or not any consumer is ready, and consumers subscribe to the events they care about.”.
Consumers
Dieser Zweig verbindet “Consumers process events asynchronously”, “The test of the architecture: add a service that reacts to existing events, and not one producer changes. This is the flexibility the pattern buys.”.
Event history
Dieser Zweig verbindet “The event log is the system of record: every state change, in order, forever. Current state is a projection that can be rebuilt from it.”, “Events can be replayed for audit or recovery”.
Verbindungen zwischen den Zweigen
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.
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
Mittleres Thema anpassen
Benennen Sie das Thema für Ihr Projekt oder Ihren Unterricht um.
Zweige ausbauen
Bearbeiten Sie Ideen und ergänzen Sie Beispiele oder Notizen.
Ideen verbinden
Zeichnen Sie Verbindungen zwischen Zweigen; Pfeile zeigen eine wichtige Richtung an.
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 Mindmap in QueryChart bearbeiten
Öffnen Sie die Mindmap auf einer bearbeitbaren Leinwand. Verschieben Sie Ideen und ergänzen Sie Zweige und Verbindungen.