+
Event Sourcing
CQRS
Neue Ideen für die Datenhaltung
Database
Domain
Wofür steht CQRS?
Command and Query Responsibility Segregation
Commands: Verändern den Zustand eines Systems. Liefern keine Daten zurück
Queries: Liefern Daten. Beeinflussen den Zustand eines Systems nicht
NEventStore
"NEventStore is a persistence library used to abstract different storage implementations when using event sourcing as storage mechanism"
Speicherung von Events
Sql/NoSql
Event-Stream
Command- und Query-Stack
Snapshots
Event-Replay
Command-Stack mit Service Bus
Integration verteilter Dienste
Veränderte Event-Daten?
Veränderte Methoden?
Eingabe-Logik komplizierter als Ausgabe
Command-Stack mit Service Bus
What-if-scenarios
NServiceBus-Framework
NServiceBus Saga
CQRS - Zusammenfassung
Ursprünglich "erfunden" von Bertrand Meyer
Mythen
Vorteile
Eiffel Programmiersprache
CQRS == ES && ES == CQRS
passende Modelle für Schreib- und Lesezugriff
CQRS funktioniert nur mit Eventual consistency
Lesezugriff kann mit simplen Technologien erfolgen, z.B. .Net DataReader, Dto-Klassen (+ Automapper)
Definiert von Young und Dahan
Unterschiedliche Datenbanken für Lesen/Schreiben
Was CQRS nicht ist
Was CQRS ist
Asymmetrisches Skalieren
Architektur-Pattern
Aufteilung der Klassen im Hinblick auf Commands und Queries
Message queues
Nachteile / Risiken
Service bus
Event sourcing
"Used when it shouldn't"
Eventual consistency ???
Service bus ???
CQRS benötigt Messages Queues / Services Bus
"Tracking anything that happened"
Welchen Vorteil bringt es uns?
So while CQRS is a pattern I'm happy to have in my toolbox, I wouldn't keep it at the top.