62-mal heruntergeladen
Hochgeladen vonMichael Plöd
Event Sourcing: Einführung und Best Practices
Das Dokument behandelt Event Sourcing als Architekturstil, der den Zustand von Anwendungen aus einer Sequenz von Ereignissen ableitet und dabei häufige Probleme traditioneller Architekturen adressiert. Es stellt Best Practices vor, wie Ereignisse verwaltet und gespeichert werden, und diskutiert Herausforderungen wie Konsistenz und Validierung in Systemen, die auf Event Sourcing und CQRS basieren. Beispielhafte Implementierungen und technologische Überlegungen werden hervorgehoben, um eine flexible und skalierbare Architektur zu schaffen.
Event Sourcing: Einführung und Best Practices
- 1. Event SourcingEinführung &Best Practices
- 2. Michael Plöd Principal Consultantbei innoQ @bitboss
- 3. Die klassische, bewährte N-TierSoftware- Architektur
- 4.
- 5.
- 6. 1 Wir lesen undschreiben Daten über den identischen Weg IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Netzwerk Netzwerk WRITE READ
- 7. 2 Wir verwenden fürLesen und Schreiben das gleiche Modell IncidentSOAPEndpoint IncidentBusinessService IncidentDAO Incident Business Model Client Incident DTO Incident View Model RDBMS Incident ER-Model Netzwerk Netzwerk
- 8.
- 9. Die meisten Systeme speichernderzeit nur den aktuellen Zustand beim Verarbeiten von Transaktionen
- 10. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUMTEXT 1 23423 11.03.2014 Maus defekt 2 67454 12.03.2014 EMail Empfang 3 93729 12.03.2014 Monitor defekt … … … … Klassische Architektur
- 11. IncidentRestController IncidentBusinessService IncidentDAO Incident ID USER_ID DATUMTEXT 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
- 12. So haben wirdas schon immer gemacht!
- 13. Zahlreiche Anwendungen fahren mitder klassischen Architektur gut
- 14. Es gibt dennochBereiche, in denen dieses Architekturmodell an seine Grenzen stößt
- 15.
- 16. 1 Das Datenmodellist ein Kompromiss 2 Lesen und Schreiben können nicht unabhängig voneinander skaliert werden 3 Keine Historie, keine Snapshots, kein Replay 4 Tendenz zum Monolithen
- 17. Event Sourcing istein Architekturstil bei dem der Zustand der Daten einer Anwendung aus einer Sequenz von Domain Events bestimmt wird
- 18. Aufbau / Bestandteile Anwendung EventBus (Queue) Anwendung stellt Events asynchron in Queue Event Handler Handler verarbeitet Events und reagiert darauf Event Store Store speichert sämtliche Events
- 19. Den Verlauf derEvents in der Queue nennt man Event Stream tjetzt EventEventEventEventEvent
- 20. Exemplarischer Event Stream IncidentCreatedEvent incidentNumber: 1 userNumber:23423 timestamp: 11.03.2014 12:23:23 text: „Mouse broken“ status: „open“ IncidentTextChangedEvent incidentNumber: 1 text: „Left button of mouse broken“ IncidentClosedEvent incidentNumber: 1 solution: „Mouse replaced“ status: „closed“
- 21. Ein Event istetwas, das in der Vergangenheit passiert ist t jetzt EventEventEventEventEvent
- 22. Die Benennung vonEvents ist Teil der Ubiquitous Language D D D
- 23.
- 24. Code Beispiel public classCustomerVerifiedEvent { private String eventId; private Date eventDate; private CustomerNumber customerNumber; private String comment; public CustomerVerifiedEvent(CustomerNumber custNum, String comment) { this.customerNumber = cusNum; this.comment = comment; this.eventDate = new Date(); } }
- 25. Scoping von Eventsauf Basis von Aggregaten D D D
- 26. Ein Event istimmer immutable Es gibt auch kein Delete!
- 27. Ein Delete ist einfach einweiterer Event IncidentCreatedEvent incidentNumber: 1 userNumber: 23423 timestamp: 11.03.2014 12:23:23 text: „Maus defekt“ status: „offen“ IncidentTextChangedEvent incidentNumber: 1 text: „Maus ist Kaputt“ IncidentClosedEvent incidentNumber: 1 solution: „Neue Maus“ status: „geschlossen“ IncidentRemovedEvent incidentNumber: 1
- 28. t now EventEventEventEventEvent Der Event Buswird üblicherweise durch einen Message Broker implementiert
- 29. Lasst uns denESB aus dem gescheiterten SOA Projekt nehmen
- 30.
- 31.
- 32.
- 33. ! Dumb pipeswith smart endpoints
- 34. 1 Kompletter Rebuild möglich 2Zeitbasierte Abfragen 3 Event Replay
- 35. Das Event Log hateinen sehr hohen Business Value
- 36. Laufe ich beiAbfragen nicht in ein Performance Problem, wenn ich den Zustand aus dem Event Store errechnen muss
- 37. Ja, vor allem beivielen Events
- 38. Application State Vorhalten von Application State Anwendung Event Queue Event Handler Event Store Application State DieAnwendung stellt Abfragen gegen den Application State
- 39.
- 40.
- 41.
- 42.
- 43. IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO RDBMS Netzwerk IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO Getrenntes Model Read Model Write Model Achtung: aktuelllaufen beide Models noch auf ein gemeinsames Datenbank- Modell zusammen
- 44. Was wäre dennein sauberer Weg für die Trennung des Datenmodells?
- 45. Event Sourcing &CQRS Event Store EventHandler EventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- 46. 1 Individuelle Skalier-und Deploybarkeit 2 Technologie-Freiheit für Query-, Command- und EventHandler Code 3 Sehr guter Fit für Bounded Context (Domain Driven Design)
- 47. Event Sourcing und CQRSsind interessante Optionen. Allerdings gibt es diverse Herausforderungen
- 48. 1 Konsistenz 2 Validierung 3Parallele Updates
- 49.
- 50. ! Systeme, die auf CQRSund Event Sourcing basieren, sind eventually consistent
- 51. Eventual Consistency Event Store EventHandlerEventsEvents IncidentCommandEndpoint IncidentCommandService IncidentCommandDAO IncidentQueryEndpoint IncidentQueryService IncidentQueryDAO Read Storage Events READ
- 52.
- 53. Ihre Fachdomäne sollteden Konsistenz-Grad treiben, nicht Technologien Deeper Insight D D D
- 54. 1 Konsistenz 2 Validierung 3Parallele Updates
- 55. User Guid id String email Stringpassword RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email Beispiel Domäne
- 56. Wir verarbeiten mehrals 2 Mio Registrierungen pro Tag. Ein Nutzer kann ihre / seine Email-Adresse ändern. Selbige muss unique sein.
- 57. ? Wie hoch istdie Wahrscheinlichkeit, das eine Validierung fehl schlägt? Welche Daten werden benötigt und wo werden diese gespeichert?
- 58. € Was ist derImpact einer fehlerhaften Validierung? Wie hoch sind die Kosten? Wie hoch ist die Wahrscheinlichkeit, dass ein Fehler auftritt?
- 59. Ihre Fachdomäne sollteden Konsistenz-Grad für Validierungen treiben Deeper Insight D D D
- 60. 1 Validiere überden Event Store 2 Validiere über den Read Store 3 Führe Validierung im Event Handler durch
- 61.
- 62. 1 Konsistenz 2 Validierung 3Parallele Updates
- 63. User Guid id String email Stringpassword RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email Beispiel Domäne
- 64. Was passiert wenn sichAlice und Bob einen Account teilen und beide ändern parallel die EMail- Adresse?
- 65. ? Was würden wirin einer „klassischen old school Architektur“ machen
- 66. UserRestController UserBusinessService UserDAO User ID EMAIL PASSWORD …… … 2341 alice_bob@xyz.com lksjdaslkdjas … … … Pessimistisches oder optimistisches Locking Update
- 67. ! Pessimistisches Locking auf Datenebene wird mitEvent Sourcing nicht funktionieren
- 68. EventHandler EventsEvents Read Storage Events EventStore UserRestController UserBusinessService UserDAO User Commands Fachlicher Lock mit UserLockedEvent Fachlicher Lock
- 69. ? Benötigen wir WIRKLICH pessimistisches Locking Diemeisten „klassischen Architekturen“ laufen sehr gut mit optimistischem Locking
- 70. Einführung eines VersionFields User Guid id Long version String email String password RegisterUserCommand ChangeEmailCommand UserRegisteredEvent Guid id Date timestamp String email String password EmailChangedEvent Guid userId Date timestamp String email Long version
- 71. Jeder Schreib Event erhöhtdie Version {guid: 12, version: 0, email: alicebob@xyz.com, password: werwe2343} {guid: 12, version: 1, email: alice_bob@xyz.com, password: werwe2343} {guid: 12, version: 2, email: alice@xyz.com, password: werwe2343} UserRegisteredEvent EmailChangedEvent version: 0 EmailChangedEvent version: 1 EmailChangedEvent version: 1 EmailChangeFailedEvent
- 72. Ihre Fachdomäne treibtdie Locking Qualität Deeper Insight D D D
- 73. 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 und Domäne Sinn macht
- 74. Danke! Michael Plöd Principal Consultantbei innoQ @bitboss http://slideshare.net/mploed michael.ploed@innoq.com