Event-Driven, Teil 3: Wie man über Ereignisse spricht

Im zweiten Teil dieser Serie haben wir gesehen, welche Bausteine eine Event-getriebene Architektur ausmachen: Commands, Events, Projections und Event Streams. Dabei spielen Events eine zentrale Rolle – sie sind die Sprache, in der das System erzählt, was passiert ist.

Doch was genau ist ein Event eigentlich? Wie benennt man es? Und wie stellt man sicher, dass es fachlich sinnvoll, verständlich und nützlich ist?

Events sind fachliche Tatsachen

Ein Event beschreibt etwas, das in der Vergangenheit liegt und fachlich bedeutsam ist. Es geht nicht um technische Details („Request empfangen“ oder „Datenbankverbindung geöffnet“), sondern um Fakten, die für die Domäne relevant sind: „Buch wurde ausgeliehen“, „Mahngebühr wurde berechnet“ oder „Adresse wurde umgemeldet“.

Diese Ereignisse sind die kleinste gemeinsame Sprache zwischen Fachlichkeit und Technik. Sie dokumentieren Entscheidungen, Abläufe und Zustandsänderungen – nicht als Nachgedanke, sondern als primäres Modell.

Die Sprache der Fachlichkeit

Events sollten so formuliert sein, dass sie auch (beziehungsweise vor allem) von Fachleuten verstanden werden und – im Idealfall – wurden sie sogar gemeinsam mit ihnen entwickelt. Es geht darum, eine gemeinsame Sprache zu finden, die sowohl die Business-Perspektive als auch die technische Umsetzung trägt.

Ein gutes Event erfüllt folgende Kriterien:

• Es beschreibt eine Tatsache, keine Absicht, keinen Wunsch, keine Prognose.
• Es ist aus Sicht der Domäne verständlich und nachvollziehbar.
• Es benennt, was passiert ist, und nicht, wie es implementiert wurde.

Beispiel:

• Nicht „book created“, sondern „Buch wurde in den Bestand aufgenommen“.
• Nicht „book updated“, sondern „Buch wurde verliehen“.

Kein technisches Artefakt

Events sind keine Logzeilen, keine Debug-Ausgaben und keine reinen Transportformate. Sie bilden tatsächlich den fachlichen Kern dessen, was das System ausdrücken soll. Man kann sich ein Event daher wie einen Eintrag in einem Geschäftsbuch vorstellen – etwas, das dauerhaft dokumentiert, was geschehen ist, und auf dessen Basis Entscheidungen getroffen werden.

Wer Events als rein technische Hilfsmittel betrachtet, läuft Gefahr, ihre Bedeutung zu verwässern. Stattdessen sollten Events präzise benannt und stabil gehalten werden – denn sie bilden die langfristige Wahrheit des Systems.

Stabilität und Entwicklung

Events sind in der Regel unveränderlich. Sie werden erzeugt, gespeichert und danach nicht mehr verändert. Das bedeutet: Ein einmal veröffentlichtes Event ist Teil der Historie und muss als solches erhalten bleiben. Wenn sich Anforderungen ändern, sollte man nicht bereits vorhandene Events „anpassen“, sondern ergänzende Events einführen.

Diese Stabilität erlaubt es, Projections zu rekonstruieren, Prozesse zu debuggen und neue Anforderungen auf Basis der bestehenden Historie umzusetzen – zum Beispiel durch das Nachverarbeiten alter Events mit neuer Logik.

Veröffentlichung und Reaktion

Wenn ein Event entstanden ist, kann es nicht nur im eigenen System genutzt werden – sondern auch veröffentlicht werden. Oft geschieht das über eine Message Queue oder einen Event Bus. Dadurch können andere Teile des Systems (oder andere Systeme) darauf reagieren, ohne dass es eine direkte Kopplung gibt.

Das bedeutet: Events sind nicht nur Daten – sie sind ein Vertrag. Ein Versprechen, dass ein bestimmter Zustand eingetreten ist – und dass man sich darauf verlassen kann.

Was kommt als Nächstes?

Im nächsten Teil schauen wir uns an, was Event-getriebene Architektur wirklich bedeutet – und was häufig damit verwechselt wird. Denn nicht überall, wo Events draufstehen, ist auch Event-getriebene Architektur drin.

(mai)