Suche
Interview mit Michael Plöd

„Event Sourcing samt CQRS und Microservices sind eine sehr gute Kombination für hochperformante Anwendungen“

Hartmut Schlosser

Event Sourcing ist ein Architekturstil, in dem Änderungen am Zustand von Daten als eine Sequenz von Events festgehalten werden. Michael Plöd ( innoQ) wird diesen Ansatz in einem Workshop auf dem Software Architecture Summit vorstellen. Vorab haben wir mit ihm darüber gesprochen, für welche Art von Anwendungen Event Sourcing vorteilhaft ist und wie es sich mit Java-Bordmitteln umsetzen lässt.

JAXenter: Du behandelst auf dem Software Architecture Summit den Architektur-Stil des Event Sourcing. Worum handelt es sich dabei?

Michael Plöd: Bei Event Sourcing handelt es sich um ein Architektur Pattern, bei dem der Zustand eines System nicht „klassisch“ in Tabellen-, Graph- oder Dokumenten-Form sondern durch eine Abfolge von Domain-Events festgehalten wird. Der Zustand einer Anwendung wird somit aus der Abfolge bestimmter Events errechnet.

Ein klassisches Beispiel hierfür ist ein Konto: Der Kontostand wird hier nicht als Feld in einer Datenbank geführt, stattdessen errechnet sich der Kontostand aus der Menge der Transaktionen, die auf diesem Konto stattfinden. Allerdings wäre es äußerst inperformant, für die Queries jedesmal den Systemzustand auf Basis der Events zu errechnen. Deshalb sieht man in Systemen auf Basis von Event Sourcing häufig eine Trennung zwischen den Events, welche in einem Event Store abgelegt werden und einem optimierten Lesemodell, welches über Event Handler, die je nach nicht-funktionalen Anforderungen über eine Messaging oder Scheduling Komponente angesteuert werden, bestückt wird.

Event Sourcing wird daher häufig auch in einem Zug mit dem CQRS Pattern genannt. Dieses Pattern wurde maßgeblich von Greg Young definiert und steht für Command Query Responsibility Segregation und sieht eine Trennung von Lese- und Schreibzugriffen in Anwendungen vor. Die Schreibzugriffe werden im Command-Teil der Anwendung realisiert, wohingegen die Lesezugriffe im Query-Teil implementiert werden. Kombiniert man dieses Konzept mit Event Sourcing, erreicht man eine saubere End-To-End Trennung von Lese- und Schreibmodell, gepaart mit hochoptimierten und performanten Leseszugriffen. Mehr Details dazu werde ich auf meinem Event Sourcing Workshop am Software Architecture Summit vorstellen.

JAXenter: Für welche Art von Anwendungen ist Event Sourcing aus deiner Sicht gut geeignet – und für welche eher nicht?

Michael Plöd: Event Sourcing eignet sich primär für Anwendungen, für die die historische Entwicklung von Daten von zentraler Bedeutung ist. Man sollte jedoch nicht leichtfertig denken, dass dies nur für wenige Anwendungsfälle wie Konten oder Logistik relevant ist. Im Grunde genommen ist jeder Geschäftsprozess eine Abfolge von (Daten-)Zuständen. So lässt sich beispielsweise ein Konsumentenkredit Prozess stark vereinfacht in folgende Events zerlegen:

  • KreditAntragGestelltEvent
  • KreditAntragVonSachbearbeiterGeprüftEvent
  • BonitätsprüfungAbgeschlossenEvent
  • KreditAntragGenehmigtEvent
  • KreditAntragAbgelehntEvent
  • KreditAusgezahltEvent
  • RatenzahlungErhaltenEvent
  • RatenzahlungNichtErhaltenEvent
  • KreditZurückgezahltEvent

Sie sehen, es lohnt sich ab und an, auch außerhalb „der Box“ zu denken und seine bisherige fachliche Wahrnehmung zu hinterfragen.

Weiterhin profitieren natürlich leseintensive Anwendungen ungemein von EventSourcing. Durch Trennung des Lese- und Schreibmodells lassen sich Leseoperationen im Hinblick auf Lookup- und Infrastruktur stark optimieren. Da die Events schlussendlich der juristische Datenbestand sind, lässt sich das Lesemodell beispielsweise jederzeit auf ein memorybasiertes DataGrid auslagern.

Allerdings ist Event Sourcing natürlich eine Herangehensweise, die „eventually consistent“ ist. Anwendungsfälle, die zwingend nach ACID-Kriterien transaktional sein müssen, scheiden als geeignete Kandidaten für Event Sourcing aus. Jedoch lohnt es, diese Anforderung kritisch zu hinterfragen, man kann schließlich voll transaktional in den Event Store schreiben und das Lese Modell asynchron zu aktualisieren.

Lesen Sie auch: Architekturen bewerten – aber wie?

JAXenter: Hast du ein paar Tipps parat, wie man Event Sourcing im Java-Technologie-Umfeld umsetzen kann?

Michael Plöd: Grundsätzlich ist Event Sourcing unabhängig von bestimmten Technologien und Programmiersprachen. Da Event Sourcing vor allem bei einer Trennung von Event-Store und Lesedatenbestand seine Vorteile entfalten kann, befindet sich man sich als Architekt und Entwickler sehr schnell im Umfeld der polyglotten Persistenz. So könnte man beispielsweise MongoDB oder Redis als EventStore und Hazelcast oder MySQL als Datastores für das Lesemodell einsetzen.

Derzeit gibt es im Java-Umfeld primär eine technologische Plattform, die sich für polyglotte Persistenz empfiehlt: das Spring-Ökosystem. Mit Hilfe von Spring Data kann man problemlos und in konsistenter Weise auf relationale und nicht-relationale Datenbanken zugreifen. Weiterhin hat Spring einen sehr ausgereiften Support für diverse Messaging Technologien: RabbitMQ, Redis Pub/Sub, JMS usw.

Abschließend ist noch Spring Boot zu nennen, welches sich hervorragend für die Entwicklung von Microservices für sämtliche Komponenten in einem Event-Sourcing-basierten System eignet und somit auf einfache Weise eine unabhängige Skalierbarkeit der einzelnen Komponenten ermöglicht. Sämtliche Code-Beispiele meines Workshops werden auf Spring basieren!

JAXenter: Du erwähntest gerade Microservices. In welchem Verhältnis steht Event Sourcing zu Microservices? Komplementär – antagonistisch – agnostisch?

Michael Plöd: Microservices und Event Sourcing haben auf den ersten Blick wenig miteinander zu tun. Betrachtet man allerdings gängige Argumentationen im Microservice-Umfeld im Kontext von Event Sourcing, so stellt man fest, dass beide Ansätze sehr gut miteinander harmonieren, dies gilt vor allem für die Kombination von Event Sourcing mit CQRS: so könnte man den Command, den Query und den Event Handling Teil als asynchron entkoppelte Microservices implementieren. Mit dieser Herangehensweise wäre man in der Lage, jeden Aspekt des Systems unabhängig voneinander zu skalieren und zu releasen.

Allerdings sollte man diese Entscheidung wohlüberlegt treffen, denn die Komplexität des Systems wird dadurch selbstverständlich erhöht. Trotz dieses Bedenkens bin ich der festen Überzeugung, dass Event Sourcing samt CQRS und Microservices eine sehr gute Kombination für hochperformante, auditsichere und reaktive Anwendungen sind. Sicherlich wird mir der letzte Satz ein „Achievement unlocked“ im Buzzword Bingo bescheren, dennoch möchte ich darauf hinweisen, dass Sie die Ideen von Event Sourcing auch in einer nicht-Microservice Welt umsetzen können. Wie? Erkläre ich in meinem Workshop auf dem Software Architecture Summit. Ich freue mich!

MichaelPloedMichael Plöd ist Principal Consultant bei innoQ. Er hat über 10 Jahre praktische Consulting Erfahrung in den Bereichen Software Entwicklung und -Architektur. Sein besonderes Interesse gilt den Bereichen Software-Architekturen, Transformation / Modernisierung von Anwendungen und Architekturen sowie polyglotte Persistenz.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Ula2017-01-27 14:40:01

    Interessanter Artikel. "Eventually" wird mit "schließlich" übersetzt, sodass in dem Absatz ein Widerspruch entsteht - schade. Der Interviewpartner meint ja genau das Gegenteil. "Tentative" oder simpel "maybe" ist die richtige Verwendung.

    "Allerdings ist Event Sourcing natürlich eine Herangehensweise, die “eventually consistent” ist. Anwendungsfälle, die zwingend nach ACID-Kriterien transaktional sein müssen, scheiden als geeignete Kandidaten für Event Sourcing aus."

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.