Event Sourcing für reaktive Anwendungen

1.633 Aufrufe

Veröffentlicht am

Unter Event Sourcing versteht man einen Architekturstil, in dem Änderungen am Zustand der verwalteten Daten als eine Sequenz von Events festgehalten werden. Durch diese Herangehensweise können jederzeit Snapshots des Datenzustands erstellt und abgefragt werden. Des Weiteren ermöglicht uns das Persistieren von Events eine Optimierung der lesenden Zugriffe durch eine Denormalisierung des "Lesemodells" der Daten. Letzterer Aspekt ist derzeit durch den Architekturansatz CQRS in aller Munde.

Im Rahmen des Vortrags werde ich Ihnen eine Einführung in das Thema Event Sourcing geben und gängige Patterns rund um das Thema vorstellen. Des Weiteren werde ich erläutern, warum Event Sourcing ein sehr guter Ansatz für Architekturen im Sinne des Reactive Manifesto ist.

Veröffentlicht in: Software
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.633
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
45
Aktionen
Geteilt
0
Downloads
21
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Event Sourcing für reaktive Anwendungen

  1. 1. Event Sourcing für reaktive Anwendungen Einführung + Best Practices
  2. 2. Michael Plöd @bitboss
  3. 3. Die meisten aktuellen Systeme speichern den aktuellen Zustand beim Verarbeiten von Transaktionen
  4. 4. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUM TEXT 1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Klassische Architektur
  5. 5. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUM TEXT 1 23423 11.03.2014 Maus ist kaputt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Update Der Datensatz wird direkt geändert. 
 Keine Historie
  6. 6. 1 Audit Log nur mit extra Aufwand 2 Kein Replay 3 Snapshots nur über Backups
  7. 7. ?Probleme
  8. 8. Zahlreiche Anwendungen fahren mit der klassischen Herangehensweise gut
  9. 9. Es gibt dennoch Bereiche, in denen dieses Architekturmodell an seine Grenzen stößt
  10. 10. ?Reactive
  11. 11. ? Responsive ? Resilient ? Elastic ? Message driven
  12. 12. IncidentRestController IncidentBusinessService IncidentDAO Incident Nicht so ganz reactive… Datenbank
  13. 13. Event Sourcing ist ein Architekturstil bei dem der Zustand der Daten einer Anwendung aus einer Sequenz von Domain Events bestimmt wird
  14. 14. 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
  15. 15. Ein Event ist etwas, das in der Vergangenheit passiert ist t jetzt EventEventEventEventEvent
  16. 16. Die Benennung von Events ist Teil der 
 Ubiquitous Language D D D
  17. 17. ShipmentDeliveredEvent
 CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent WillSaveItemEvent DoStuffEvent
  18. 18. Code Beispiel public class CustomerVerifiedEvent { private CustomerNumber customerNumber; private String comment; public CustomerVerifiedEvent(CustomerNumber custNum, String comment) { this.customerNumber = cusNum; this.comment = comment; } }
  19. 19. Scoping von Events auf 
 Basis von
 Aggregaten D D D
  20. 20. Ein Event ist immer immutable !
  21. 21. Den Verlauf der Events in der Queue nennt man Event Stream tjetzt EventEventEventEventEvent
  22. 22. IncidentCreatedEvent
 
 incidentNumber: 1
 userNumber: 23423 timestamp: 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“
  23. 23. 1 Kompletter Rebuild möglich 2 Zeitbasierte Abfragen 3 Event Replay
  24. 24. Gängiges Beispiel =
 Versionskontroll-Systeme
  25. 25. Das Event Log hat einen sehr hohen Business Value
  26. 26. Es gibt kein Delete !
  27. 27. Ein Delete ist einfach ein weiterer Event IncidentCreatedEvent
 
 incidentNumber: 1
 userNumber: 23423 timestamp: 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

  28. 28. Laufe ich bei Abfragen nicht in ein Performance Problem, wenn ich den Zustand aus dem Event Store errechnen muss
  29. 29. Ja, vor allem bei vielen Events
  30. 30. Application State Vorhalten von Application State Anwendung Event Queue Event Handler Event Store Application State Die Anwendung stellt Abfragen gegen den Application State
  31. 31. CQRS
  32. 32. Command Query Responsibility Separation
  33. 33. IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident
 DTO Incident
 View
 Model RDBMS Incident
 ER-Model Netzwerk Netzwerk
  34. 34. EventHandler EventsEvents Event Sourcing & CQRS IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Lese Datenhaltung Events Select * from
  35. 35. 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
  36. 36. Danke! Michael Plöd @bitboss http://slideshare.net/mploed michael.ploed@gmail.com

×