Event-driven Architecture
Eine ereignisgetriebene Architektur veröffentlicht festgehaltene fachliche Tatsachen. Andere Bausteine reagieren darauf ohne direkten Ablaufaufruf durch den Produzenten.
- EreignisFestgehaltene fachliche Tatsache.
- Ereignis ≠ BefehlEs berichtet, was geschah, nicht was zu tun ist.
- Lose KopplungProduzent kennt keine Empfänger.
Einordnung
Warum das wichtig ist
Neue Reaktionen entstehen, ohne den Produzenten zu ändern. Ein Ereignis hält eine Tatsache fest und gibt keinen Befehl. Bestellung muss weder Versand noch Rechnung kennen. Transportformen und Zustellung vertiefen die Bausteine Pub/Sub und Outbox.
Dieser Baustein erklärt die Kopplung über fachliche Ereignisse. Für Transportformen und Zustellung siehe Queues, Pub/Sub & Streams.
Auf einen Blick · Ereignisse über einen Kanal
Wer muss sich ändern, wenn eine Reaktion dazukommt?
Im modularen Monolithen veröffentlicht Bestellung intern das Ereignis BestellungBezahlt. Versand und Rechnung reagieren mit eigenen Aufgaben.
So liest du das Bild
- Ereignis Im Ereignismodus der apricot Kasten BestellungBezahlt mit „Bestell-ID und Zeitpunkt“.
- Ereignis ≠ Befehl Das Ereignis heißt BestellungBezahlt, nicht RechnungErzeugen; jedes Modul entscheidet selbst.
- Lose Kopplung Im Ereignismodus bleibt der Zähler „Änderungen an Bestellung“ bei 0, auch wenn Lager oder Kennzahlen dazukommen.
Bestellungsetzt Status bezahlt
Code in Bestellung
versand.lieferauftragVorbereiten(b)
rechnung.belegErstellen(b)- VersandLieferauftrag vorbereitenwird aufgerufen
- RechnungBeleg erstellenwird aufgerufen
- Bestellung kennt
- 2 Module
- Änderungen an Bestellung je neuer Reaktion
- 1
Der Ablauf ist an einer Stelle lesbar und das Ergebnis sofort sichtbar, doch jede neue Reaktion ändert die Bestellung.
Nutzen & Grenzen
Hilft, wenn
- Unabhängige Reaktionen auf eine fachliche Änderung laufen über Ereignisse, ohne den Erzeuger an einzelne Empfänger zu binden.
- Nachrichten puffern Folgearbeit und entkoppeln ihre Verarbeitungszeit von der Veröffentlichung.
- Konsumenten gewinnen mit eigenen Projektionen oder Prozessen Zugriff auf dieselbe Tatsache, ohne eine synchrone Aufrufkette aufzubauen.
Grenzen
- Der Ablauf wird unsichtbar: Wer reagiert auf BestellungBezahlt? Halte Empfänger und Fortschritt sichtbar.
- Nachgelagerte Konsistenz: Die Rechnung entsteht später als die Zahlung; definiere, was Kundschaft solange sieht.
- Das Ereignisschema ist ein Vertrag mit allen Empfängern; Änderungen brauchen Versionierung.
In der Praxis
- Benenne Ereignisse als abgeschlossene Tatsachen und dokumentiere Schema, Kennung sowie Reihenfolge. So können Konsumenten den Zustand verstehen, ohne eine Entscheidung beim Produzenten auszulösen.
- Lege für jeden Konsumenten Fortschritt und Fehlerzustand fest. Eine Veröffentlichung gilt erst als fachlich verarbeitet, wenn der Empfänger seine Wirkung dauerhaft vermerkt hat.
- Prüfe Rückstand, Wiederholung und Reihenfolge je Konsument. Pub/Sub und Streams vertiefen die Verteilung; Transactional Outbox sichert den Versandvorsatz.
Ausführliche Erklärung lesen
Ein fachliches Ereignis hält eine bereits eingetretene Änderung fest. Der Erzeuger veröffentlicht die Tatsache; unabhängige Konsumenten entscheiden über ihre jeweilige Folgearbeit. Dadurch kennt der Erzeuger nicht jede nachgelagerte Komponente und kann seine eigene Zustandsänderung getrennt abschließen.
Die zeitliche Entkopplung macht Verzögerungen, Wiederholungen und Reihenfolge zu Bestandteilen des Vertrags. Veröffentlichung und erfolgreiche fachliche Wirkung bleiben verschiedene Zustände. Kennungen, Versionen und Fortschrittsinformationen helfen, Verarbeitung über mehrere Konsumenten hinweg nachvollziehbar zu halten.
Pub/Sub und Streams unterscheiden Empfängerkopplung und Aufbewahrung; Transactional Outbox sichert den lokalen Versandvorsatz einer Änderung.
Martin Fowler unterscheidet vier Bedeutungen von „event-driven“: Event Notification, Event-Carried State Transfer, Event Sourcing und CQRS. Im Shop ist BestellungBezahlt eine Event Notification mit schlanker Nutzlast: Sie meldet nur Bestell-ID und Zeitpunkt, Details fragen Empfänger bei Bedarf nach. Event-Carried State Transfer wäre sinnvoll, wenn Empfänger die Bestelldaten ohne Rückfrage brauchen, etwa weil ein anderes System sie nicht jederzeit abfragen kann.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Du schaltest im Ereignismodus das Lager zu. Was ändert sich am Code der Bestellung?
Lösung mit Begründung ansehen
Nichts. Der Zähler bleibt bei 0; Bestellung veröffentlicht weiter nur BestellungBezahlt. Das Lager meldet sich selbst als Empfänger an.
AnwendenAuf eine neue Lage übertragen
Die Belegerstellung schlägt für B-1042 fehl. Wer reagiert darauf?
Lösung mit Begründung ansehen
Das Rechnungsmodul in seiner eigenen Reaktion, etwa mit Wiederholung und Fehlerzustand. Bestellung und Versand bleiben unberührt; das Team beobachtet den Fortschritt der Rechnung.
BewertenEine Alternative abwägen
Das Team will das Ereignis RechnungJetztAlsPDFErzeugen nennen. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: Der Zweck ist sofort klar. Nachteil: Es ist ein Befehl, der Bestellung an die Rechnung und ihr Format bindet und weitere Empfänger ausschließt. Empfehlung: BestellungBezahlt nennen; die Rechnung entscheidet selbst über Beleg und Format.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft · Event-driven Architecture (öffnet in neuem Tab)Beschreibt Ereignisproduzenten, Konsumenten und operative Konsequenzen.
- Martin Fowler · What do you mean by Event-Driven? (öffnet in neuem Tab)Unterscheidet Ereignisbenachrichtigung, Zustandsübertragung und Event Sourcing.
- Microsoft · Publisher-Subscriber (öffnet in neuem Tab)Erklärt entkoppelte Ereignisverteilung und Zustellbedingungen.