Event-Driven, Teil 4: Was Event-getriebene Architektur ist – und was nicht

Event-getriebene Architektur (Event-Driven Architecture, kurz EDA) ist in den letzten Jahren zu einem beliebten Schlagwort geworden. Viele Systeme bezeichnen sich als eventbasiert – oft aber, ohne wirklich das zu tun, was EDA ausmacht.

In diesem Teil der Serie wollen wir klären, was Event-getriebene Architektur wirklich ist – und welche Missverständnisse häufig auftreten.

Was EDA nicht ist

Bevor wir definieren, was EDA bedeutet, ist es hilfreich zu klären, was es nicht ist.

Erstens: Pub/Sub ist keine Event-getriebene Architektur. Viele Systeme arbeiten mit sogenannten Topics, Queues oder Bussen: Ein Service veröffentlicht Nachrichten, ein anderer konsumiert sie. Das ist technisch gesehen Pub/Sub – ein Nachrichtenmuster.

Aber: Das allein macht noch keine Event-getriebene Architektur. Oft werden hier Nachrichten verschickt, die nichts mit Events im eigentlichen Sinne zu tun haben – etwa „setze Preis auf EUR 9,99“ oder „aktualisiere den Bestand“.

Solche Nachrichten beschreiben keine Tatsachen, sondern Anweisungen – sie sind also eher Commands.

Event-Carried State Transfer

Manche Systeme versenden ganze Datenobjekte über Events: „Produkt wurde geändert“ oder „Bestellung wurde aktualisiert“, oft inklusive vollständiger Kopie des aktuellen Zustands. Das nennt man „Event-Carried State Transfer“.

Auch hier ist das Wort „Event“ im Spiel – aber es handelt sich nicht um eine dokumentierte, interpretierbare Historie. Es ist ein Transportmechanismus, nicht mehr. EDA hingegen geht von fachlichen Ereignissen aus – nicht von Datenzuständen.

EDA ist keine Technik, sondern ein Denkmodell

Oft wird EDA mit bestimmten Tools oder Technologien assoziiert: Kafka, EventBridge, RabbitMQ und so weiter. Aber diese Tools sind nicht EDA – sie ermöglichen sie vielleicht, aber sie sind es nicht.

Event-getriebene Architektur ist zuerst ein Denkmodell: Es geht darum, Systeme so zu gestalten, dass sie sich an dem orientieren, was in der Fachlichkeit geschieht – an den Ereignissen.

Was EDA ist

Eine Event-getriebene Architektur orientiert sich an folgenden Prinzipien:

• Fachliche Ereignisse stehen im Mittelpunkt. Das System dokumentiert, was passiert ist – nicht nur, wie der aktuelle Zustand aussieht.
• Abläufe entstehen durch Reaktion auf Events. Systeme reagieren auf Ereignisse – synchron oder asynchron – und leiten daraus neue Aktionen oder Entscheidungen ab.
• Prozesse sind lose gekoppelt. Einzelne Komponenten wissen wenig voneinander – sie tauschen keine direkten Aufrufe aus, sondern reagieren auf gemeinsam verstandene Ereignisse.
• Die Architektur bildet die Fachlichkeit ab. Die Struktur des Codes, der Kommunikation und der Abläufe folgt dem, was im Unternehmen oder der Domäne tatsächlich geschieht.

Und was ist dann CQRS?

CQRS (Command Query Responsibility Segregation) ist ein Architekturprinzip, das häufig im Kontext von EDA auftaucht. Es bedeutet: Schreib- und Lesezugriffe werden getrennt behandelt. Änderungen erfolgen über Commands, Lesefunktionen greifen auf optimierte Projektionen zu.

CQRS ist kein Muss für EDA – aber es passt sehr gut dazu, weil es viele Herausforderungen elegant löst:

• Commands führen zu Events.
• Events aktualisieren Projections.
• Queries lesen ausschließlich aus Projections.

Das Ergebnis ist ein System mit klaren Verantwortlichkeiten, entkoppelten Prozessen und hoher Nachvollziehbarkeit.

Was kommt als Nächstes?

Der nächste Teil wird zeigen, welche Eigenschaften gute Events ausmachen – und welche typischen Fallstricke man vermeiden sollte, wenn man mit Event-getriebener Architektur arbeitet.

(mai)