The Architecture Gathering 2015
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 „Lese-Modells“ der Daten. Letzerer Aspekt ist aktuell insbesondere durch den Architekturansatz CQRS in aller Munde.
6. 1
Wir lesen und schreiben
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ür Lesen
und Schreiben das gleiche
Modell
IncidentSOAPEndpoint
IncidentBusinessService
IncidentDAO
Incident
Business
Model
Client
Incident
DTO
Incident
View
Model
RDBMS
Incident
ER-Model
Netzwerk
Netzwerk
16. 1 Das Datenmodell ist 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 ist ein
Architekturstil bei dem
der Zustand der Daten
einer Anwendung aus
einer Sequenz von
Domain Events bestimmt
wird
18. Aufbau / Bestandteile
Anwendung
Event Bus
(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 der Events in
der Queue nennt man
Event Stream
tjetzt
EventEventEventEventEvent
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
CQRS sind
interessante
Optionen. Allerdings
gibt es diverse
Herausforderungen
55. User
Guid id
String email
String password
RegisterUserCommand ChangeEmailCommand
UserRegisteredEvent
Guid id
Date timestamp
String email
String password
EmailChangedEvent
Guid userId
Date timestamp
String email
Beispiel Domäne
56. Wir verarbeiten mehr als 2
Mio Registrierungen pro Tag.
Ein Nutzer kann ihre / seine
Email-Adresse ändern. Selbige
muss unique sein.
57. ?
Wie hoch ist die
Wahrscheinlichkeit, das
eine Validierung fehl
schlägt?
Welche Daten werden
benötigt und wo werden
diese gespeichert?
58. €
Was ist der Impact
einer fehlerhaften
Validierung?
Wie hoch sind die
Kosten?
Wie hoch ist die
Wahrscheinlichkeit,
dass ein Fehler
auftritt?
59. Ihre Fachdomäne sollte den
Konsistenz-Grad für
Validierungen treiben
Deeper Insight
D D D
60. 1 Validiere über den
Event Store
2 Validiere über den
Read Store
3 Führe Validierung im
Event Handler durch
63. User
Guid id
String email
String password
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
sich Alice und Bob einen
Account teilen und beide
ändern parallel die EMail-
Adresse?
65. ?
Was würden wir in
einer „klassischen old
school Architektur“
machen
70. Einführung eines Version Fields
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
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