Nachdem sich die bisherigen Teile dieser Serie mit den Grundlagen Event-getriebener Architektur beschäftigt haben, soll es nun konkret werden. Anhand eines durchgehenden Beispiels werde ich zeigen, wie sich ein System von Grund auf modellieren lässt – nicht ausgehend von Tabellen, Datenbanken oder APIs, sondern ausgehend von den fachlichen Vorgängen selbst.

Dieses Beispiel ist bewusst einfach gehalten, aber dennoch realistisch: eine Stadtbibliothek.

Fachlichkeit im Mittelpunkt

In dieser Bibliothek können Benutzerinnen und Benutzer Bücher ausleihen, verlängern und zurückgeben. Geben sie Bücher zu spät zurück, fallen Mahngebühren an. All diese Vorgänge folgen festen fachlichen Regeln – und genau dort setzt unser Architekturansatz an: Wir fragen nicht zuerst nach Datenstrukturen, sondern nach dem, was passiert.

Damit wird schnell klar, worum es in der Event-getriebenen Architektur geht: um Ereignisse. Statt den aktuellen Zustand zentral zu modellieren, konzentrieren wir uns auf die Vorgänge, die zu diesem Zustand führen. Ein System beschreibt nicht einfach, wie etwas ist, sondern erzählt, was vorgefallen ist.

Was passiert in der Domäne?

Bevor überhaupt an eine Implementierung zu denken ist, beginnen wir mit einem Perspektivwechsel: Welche fachlich relevanten Ereignisse treten in der Domäne überhaupt auf?

Für unsere Stadtbibliothek ergeben sich schnell typische Beispiele:

• „Buch wurde ausgeliehen.“
• „Buch wurde zurückgegeben.“
• „Leihfrist wurde verlängert.“
• „Rückgabe war verspätet.“
• „Mahngebühr wurde fällig.“
• „Mahngebühr wurde bezahlt.“

Diese Events beschreiben konkrete Tatsachen – nicht bloße Zustände, sondern Veränderungen. Sie machen sichtbar, was passiert ist, wann es passiert ist und, je nach Eventstruktur, auch warum.

Ein typischer Ablauf

Als Beispiel dient hier ein klassischer Ausleihvorgang. Der Benutzer leiht ein Buch aus – das System erzeugt das Event „Buch wurde ausgeliehen“. Wird das Buch nicht fristgerecht zurückgegeben, stellt das System fest, dass die Rückgabe verspätet ist – „Rückgabe war verspätet“. Als Folge davon wird eine Mahngebühr fällig. Auch das ist ein Event: „Mahngebühr wurde fällig“. Bezahlt der Benutzer diese Gebühr, entsteht das nächste Event – „Mahngebühr wurde bezahlt“. Und schließlich: „Buch wurde zurückgegeben.“

Was auffällt: Es ist nicht notwendig, den Status des Buches zentral zu speichern, sondern der gesamte Ablauf ergibt sich aus der Abfolge der Ereignisse. Der aktuelle Zustand kann jederzeit aus der Historie rekonstruiert werden. Und mehr noch: Die gesamte Geschichte bleibt nachvollziehbar.

Commands führen zu Events

Natürlich entstehen Events nicht von selbst. Meistens gehen ihnen sogenannte Commands voraus – also Aufforderungen an das System, etwas zu tun. Wenn eine Benutzerin oder ein Benutzer ein Buch ausleihen möchte, sendet sie oder er ein Command wie „Leihe Buch aus.“ Das System prüft, ob das Command zulässig ist – ist das der Fall, erzeugt es das entsprechende Event: „Buch wurde ausgeliehen.“

Wichtig ist dabei die Trennung: Commands drücken Absichten aus, Events dokumentieren Fakten. Nicht jedes Command führt zu einem Event – wenn die Voraussetzungen nicht erfüllt sind, kann ein Command abgelehnt werden. Diese Trennung hilft dabei, Abläufe präzise zu modellieren und Fachlichkeit sauber umzusetzen.

Projections machen den Zustand sichtbar

Aus den gespeicherten Event kann jederzeit der aktuelle Zustand berechnet werden. Dazu dienen sogenannte Projections – lesbare, abfragbare Sichten auf das System. Eine Projection beantwortet Fragen wie: Welche Bücher hat ein Benutzer gerade ausgeliehen? Welche Mahngebühren sind offen? Wann wurde ein bestimmtes Buch zuletzt zurückgegeben?

Diese Projections enthalten keine eigene Logik. Sie basieren ausschließlich auf der Verarbeitung von Events. Ihr großer Vorteil: Sie lassen sich gezielt für bestimmte Anwendungsfälle optimieren, ohne dass dies Auswirkungen auf andere Teile des Systems hätte.

Die Architektur folgt der Fachlichkeit

Durch diese Herangehensweise entsteht eine Architektur, die eng an der Fachlichkeit orientiert ist. Statt technischer Artefakte stehen tatsächliche Abläufe im Zentrum. Die Fachsprache wird zum Strukturgeber des Systems. Events dienen dabei nicht nur als interne Verarbeitungsgrundlage, sondern oft auch als Kommunikationsmittel zwischen Komponenten oder Systemen – etwa, indem sie über eine Message Queue veröffentlicht und von anderen Diensten abonniert werden.

Die Vorteile liegen auf der Hand: Systeme werden modularer, verständlicher und besser wartbar. Änderungen sind nachvollzieh- und neue Anforderungen sind oft durch das Hinzufügen neuer Reaktionen auf bestehende Events umsetzbar. Die Trennung von Schreiben und Lesen (Command Query Responsibility Segregation, CQRS) führt zudem zu klareren Verantwortlichkeiten und besserer Skalierbarkeit.

Fazit

Dieses Beispiel einer Stadtbibliothek zeigt, wie Event-getriebene Architektur in der Praxis gedacht werden kann. Entscheidend ist nicht die konkrete technische Umsetzung, sondern der Perspektivwechsel: Weg vom aktuellen Zustand, hin zur Historie der fachlichen Ereignisse.

Im nächsten und letzten Teil dieser Serie wird es darum gehen, wie man mit Event-getriebener Architektur in einem echten Projekt startet: Welche Rollen beteiligt sind, wie man Events mit Fachleuten entwickelt – und welche Schritte für erste Experimente besonders geeignet sind.

(mai)