Event-Driven, Teil 2: Die Bausteine von Event-getriebener Architektur

Der erste Teil dieser Serie hat gezeigt, warum klassische Architekturen wie CRUD oder REST an ihre Grenzen stoßen – vor allem, wenn die Fachlichkeit komplexer wird. Doch was ist die Alternative?

Event-getriebene Architekturen (Event-Driven Architecture, kurz EDA) orientieren sich nicht am Datenmodell, sondern an den Vorgängen in der Domäne. Sie setzen auf ein anderes Vokabular, andere Bausteine – und führen zu einem völlig anderen Systemaufbau. Dieser Teil betrachtet die wichtigsten Elemente im Überblick.

Commands: Anweisungen an das System

Ein Command ist eine Aufforderung, etwas zu tun. Es ist ein gerichteter, imperativer Aufruf wie beispielsweise „Verleihe dieses Buch“, „Melde diese Adresse um“ oder „Überweise diesen Betrag“. Commands kommen fast immer von außen, etwa aus einer Benutzeroberfläche, einem anderen System oder einem automatisierten Prozess.

Wichtig ist dabei zu beachten, dass ein Command an sich noch keine Garantie dafür ist, dass etwas geschieht – sondern nur der Versuch, etwas auszulösen. Ob ein Command gültig ist, entscheidet die Domäne: Das System prüft, ob das Command erlaubt ist und ob die fachlichen Bedingungen erfüllt sind.

Events: Was passiert ist

Events sind die Folge von Commands. Sie entstehen als Konsequenz aus den fachlichen Entscheidungen, die beim Verarbeiten des Commands getroffen wurden.

Ein Event beschreibt daher eine fachlich relevante Tatsache, die in der Vergangenheit liegt. Es ist nicht „Bitte mache X“, sondern „X ist geschehen“. Events sind neutral, beschreibend und oft dauerhaft gespeichert. Sie bilden die zentrale Informationsquelle im System.

Passende Beispiele (zu den zuvor genannten Commands) könnten sein: „Buch wurde verliehen“, „Adresse wurde umgemeldet“ oder „Betrag wurde überwiesen“.

Events sind nicht nur nützlich für das System selbst, sondern auch für andere Beteiligte: Sie können andere Prozesse anstoßen, Systeme informieren oder Änderungen in Datenprojektionen auslösen.

Event Streams: Die Geschichte einzelner Objekte

Ein Event Stream ist die zeitlich geordnete Liste aller Events zu einem bestimmten Kontext – etwa zu einer Benutzerin oder einem Benutzer, einem Konto oder einem Buch. Er enthält nur die Ereignisse, die für genau dieses Objekt relevant sind.

Aus einem solchen Stream lässt sich jederzeit der aktuelle Zustand eines Objekts rekonstruieren. Das macht Systeme sehr transparent und nachvollziehbar: Man sieht nicht nur den Status quo, sondern auch, wie es im Laufe der Zeit dazu kam.

Projections: Leseseiten des Systems

Projections dienen schließlich der dauerhaften Abbildung des aktuellen Zustands – sie beantworten Fragen wie: „Wer hat welches Buch ausgeliehen?“, „Wie hoch ist das aktuelle Guthaben?“ oder „Was ist der letzte bekannte Wohnsitz?“.

Sie basieren ausschließlich auf den Events: Aus der Historie dessen, was geschehen ist, wird der aktuelle Zustand berechnet. Dabei kann es viele verschiedene Projektionen gleichzeitig geben – je nachdem, welche Sichten gebraucht werden.

Projections sind oft speziell auf einzelne Anwendungsfälle zugeschnitten und können effizient für Lesezugriffe optimiert werden, unabhängig von der Schreiblogik.

Wie diese Bausteine zusammenspielen

Ein typischer Ablauf in einem Event-basierten System sieht dann wie folgt aus:

• Eine Anwenderin oder ein Anwender löst ein Command aus (zum Beispiel über eine Interaktion im UI).
• Das System prüft, ob das Command zulässig ist.
• Ist er zulässig, werden ein oder mehrere Events erzeugt und gespeichert.
• Diese Events fließen in Event Streams, aktualisieren Projections, werden gegebenenfalls über Message Queues veröffentlicht und von anderen Systemen konsumiert.

Im Ergebnis erhält man eine klare Trennung von der ursprünglichen Intention (Command) und dem anschließenden Ergebnis (Event), eine transparente Dokumentation der Vorgänge und ein System, das sowohl intern als auch extern nachvollziehbar bleibt.

Was kommt als Nächstes?

Im nächsten Teil wird es darum gehen, was ein Event aus fachlicher Sicht überhaupt ist – und warum es so wichtig ist, sich dabei nicht von technischen Details ablenken zu lassen. Denn Events sind keine Logeinträge – sie sind die Sprache der Fachlichkeit.

(mai)