Embed Size (px)
Citation preview
Event Sourcingfür reaktive Anwendungen
Einführung + Best Practices
Michael Plöd@bitboss
Die meisten aktuellen Systeme speichern den aktuellen Zustand beim
Verarbeiten von Transaktionen
IncidentRestController
IncidentBusinessService
IncidentDAO
Incident
ID USER_ID DATUM TEXT1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang3 93729 12.03.2014 Monitor defekt… … … …
Klassische Architektur
IncidentRestController
IncidentBusinessService
IncidentDAO
Incident
ID USER_ID DATUM TEXT1 23423 11.03.2014 Maus ist kaputt2 67454 12.03.2014 EMail Empfang3 93729 12.03.2014 Monitor defekt… … … …
Update
Der Datensatz wird direkt geändert. Keine Historie
1 Audit Log nur mit extra Aufwand
2 Kein Replay
3 Snapshots nur über Backups
? Probleme
Zahlreiche Anwendungen fahren mit der klassischen
Herangehensweise gut
Es gibt dennoch Bereiche, in denen dieses
Architekturmodell an seine Grenzen stößt
? Reactive
? Responsive
? Resilient
? Elastic
? Message driven
IncidentRestController
IncidentBusinessService
IncidentDAO
Incident
Nicht so ganz reactive…
Datenbank
Event Sourcing ist ein Architekturstil bei dem der Zustand der Daten einer Anwendung aus
einer Sequenz von Domain Events bestimmt
wird
Aufbau / Bestandteile
Anwendung
Event Queue
Anwendung stellt Events asynchron
in Queue
Event Handler
Handler verarbeitet Events und reagiert
darauf
Event Store
Store speichert sämtliche Events
Ein Event ist etwas, das in der Vergangenheit
passiert ist
tjetzt
EventEventEventEventEvent
Die Benennung von Events ist Teil der
Ubiquitous Language
D D D
ShipmentDeliveredEvent
CustomerVerifiedEvent
CartCheckedOutEvent
CreateCustomerEvent WillSaveItemEvent
DoStuffEvent
Code Beispielpublic class CustomerVerifiedEvent {
private CustomerNumber customerNumber;
private String comment;
public CustomerVerifiedEvent(CustomerNumber custNum, String comment) {this.customerNumber = cusNum;this.comment = comment;
}
}
Scoping von Events auf Basis von
Aggregaten
D D D
Ein Event ist immer immutable!
Den Verlauf der Events in der Queue nennt man
Event Stream
tjetzt
EventEventEventEventEvent
IncidentCreatedEvent incidentNumber: 1 userNumber: 23423timestamp: 11.03.2014 12:23:23 text: „Maus defekt“status: „offen“
Beispielhafter Event Stream
IncidentUpdatedEvent incidentNumber: 1 text: „Maus ist Kaputt“
IncidentUpdatedEvent incidentNumber: 1 solution: „Neue Maus“status: „geschlossen“
1 Kompletter Rebuild möglich
2 Zeitbasierte Abfragen
3 Event Replay
Gängiges Beispiel
=Versionskontroll-Systeme
Das Event Log hat einen sehr
hohen Business Value
Es gibt kein Delete!
Ein Delete ist einfach
ein weiterer Event
IncidentCreatedEvent incidentNumber: 1 userNumber: 23423timestamp: 11.03.2014 12:23:23 text: „Maus defekt“status: „offen“
IncidentUpdatedEvent incidentNumber: 1 text: „Maus ist Kaputt“
IncidentUpdatedEvent incidentNumber: 1 solution: „Neue Maus“status: „geschlossen“
IncidentRemovedEvent incidentNumber: 1
Laufe ich bei Abfragen nicht in ein Performance
Problem, wenn ich den Zustand aus dem Event Store
errechnen muss
Ja, vor allem bei vielen
Events
Application State
Vorhalten von Application State
Anwendung
Event Queue
Event Handler
Event Store
Application State
Die Anwendung stellt Abfragen gegen den
Application State
CQRS
Command Query Responsibility Separation
IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
IncidentBusiness Model
Client
Incident DTO
Incident View Model
RDBMS
Incident ER-Model
Netzwerk
Netzwerk
EventHandler EventsEvents
Event Sourcing & CQRSIncidentCommandEndpoint
IncidentCommandService
IncidentCommandDAO
IncidentQueryEndpoint
IncidentQueryService
IncidentQueryDAO
Lese Datenhaltung
Events
Select * from
ToolsEvent
Sourcing
Hazelcast, RabbitMQ, MQSeries, RDBMS, MongoDB, Redis, Apache Kafka, und viele
mehr
Treiben Sie das Thema Event Sourcing nicht aus Tooling Sicht sondern adaptieren Sie, das
was für Ihre Organisation Sinn macht
