Praktischer Einstieg in die Event-getriebene Architektur
Die Serie über die Grundlagen der Event-getriebenen Architektur wechselt jetzt zu einem praktischen Fokus. Im folgenden Beispiel wird aufgezeigt, wie ein System von Grund auf modelliert werden kann, indem man sich auf die fachlichen Vorgänge konzentriert.
Das gewählte Beispiel ist eine Stadtbibliothek. In dieser können Benutzer Bücher ausleihen, verlängern und zurückgeben. Bei verspäteter Rückgabe fallen Mahngebühren an, die natürlich den festen Regeln des Fachgebiets folgen. Der Ansatz der Architektur liegt darauf, nicht zuerst nach Datenstrukturen zu fragen, sondern nach den tatsächlichen Ereignissen, die in der Domäne geschehen.
Zentrale Ereignisse in der Domäne
Bevor die Implementierung beginnen kann, ist es wichtig, relevanten Ereignisse in der Domäne zu identifizieren. Für die Stadtbibliothek sind dies:
- „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 erfassen wichtige Entwicklungen und die Veränderungen, die innerhalb des Systems stattfinden. Sie zeigen nicht nur an, was passiert ist, sondern auch die Zeitpunkte und die Kontextinformationen.
Ein typischer Ausleihvorgang
Ein klassischer Ausleihvorgang beginnt damit, dass der Benutzer ein Buch ausleiht. Darauf folgt das Event „Buch wurde ausgeliehen“. Wenn die Rückgabe verspätet erfolgt, wird das Event „Rückgabe war verspätet“ generiert und es folgt die Mahngebühr, die aus einem weiteren Event resultiert: „Mahngebühr wurde fällig“. Mit der Zahlung der Mahngebühr wird das Event „Mahngebühr wurde bezahlt“ erstellt, gefolgt von der Rückgabe des Buches, was das Event „Buch wurde zurückgegeben“ auslöst.
Ein zentraler Punkt hierbei ist, dass es nicht erforderlich ist, den Status des Buches ständig im System zu speichern. Der gesamte Ablauf ergibt sich aus der Abfolge der Ereignisse, aus der der aktuelle Zustand zu jedem Zeitpunkt rekonstruiert werden kann. Dies gewährleistet Nachvollziehbarkeit und Transparenz.
Commands und deren Auswirkungen
Events entstehen in der Regel durch sogenannte Commands, die die Absicht der Benutzer repräsentieren. Möchte ein Benutzer ein Buch ausleihen, sendet er den Command „Leihe Buch aus“. Das System überprüft die Berechtigung und generiert daraufhin das zugehörige Event: „Buch wurde ausgeliehen“.
Wichtig ist die klare Trennung zwischen Commands, die absichtliche Handlungen wiedergeben, und Events, die Fakten dokumentieren. Nicht jeder Command führt zu einem Event, sodass wenn die Bedingungen nicht stimmen, ein Command abgelehnt werden kann. Diese Unterscheidung erleichtert die präzise Modellierung der Abläufe.
Sichtbarkeit des Systemzustands
Aus den gespeicherten Events kann jederzeit der aktuelle Zustand generiert werden. Dies geschieht über sogenannte Projections, die eine lesbare und abfragbare Sicht auf die Systemzustände bieten. Sie beantworten beispielsweise Fragen zu den aktuell ausgeliehenen Büchern, offenen Mahngebühren oder dem letzten Rückgabezeitpunkt eines bestimmten Buches.
Projections sind nicht mit einer eigenen Logik ausgestattet und basieren lediglich auf der Verarbeitung der Events. Ihr wesentlicher Vorteil liegt in der Möglichkeit, sie gezielt für spezifische Anwendungsfälle zu optimieren, ohne andere Teile des Systems zu beeinträchtigen.
Architektur im Dienste der Fachlichkeit
Diese Herangehensweise fördert eine Architektur, die eng an den fachlichen Anforderungen orientiert ist. Es stehen echte Abläufe im Zentrum, während technische Artefakte in den Hintergrund treten. Die Sprache der Fachlichkeit wird zentral, und Events dienen nicht nur der internen Verarbeitung, sondern auch der Kommunikation zwischen verschiedenen Systemkomponenten.
Die Vorteile dieser Methodik sind signifikant: Systeme werden modular, verständlicher und wartungsfreundlicher. Änderungen lassen sich oft durch das Hinzufügen neuer Reaktionen auf bestehende Events implementieren, was die Anforderungen der Fachlichkeit schnell umsetzt. Zudem bietet die Trennung von Kommandos und Abfragen (CQRS) klarere Verantwortlichkeiten und eine bessere Skalierbarkeit.
Zusammenfassung
Das Beispiel der Stadtbibliothek verdeutlicht, wie Event-getriebene Architektur in der Praxis verwendet werden kann. Von entscheidender Bedeutung ist der Perspektivwechsel, weg vom gegenwärtigen Zustand hin zur Historie der Ereignisse, die das System geprägt haben.
Im nächsten Teil dieser Serie wird durch das praktische Beispiel veranschaulicht, wie man in einem echten Projekt mit Event-getriebener Architektur beginnt: Von den beteiligten Rollen bis zu den Schritten für die ersten Experimente.
