This document discusses CQRS and event sourcing patterns. It begins with an overview of CQRS, explaining how separating commands and queries can help with consistency in distributed systems. It then covers event sourcing, where all state changes are stored as a sequence of events. Benefits of event sourcing include preserving history and ability to replay events to reset state. The document provides examples of how CQRS and event sourcing could be applied to a domain like a rock-paper-scissors game.
8. Eventual Consistency
User A
User B
Get
Get
Buy!
Buy!
!
One ticket left!
One ticket left!
User C Get Buy!
!
One ticket left!
User D Get
No tickets!
Buy!
!
One ticket left!
9. CQRS
Command Query Responsibility Segregation!
Commands - action that will modify state!
Queries - anything that view state!
The handling of commands and queries are separated
12. Validation vs Business rules
Validation!
Correct structure!
Ranges, lengths, types!
Rules!
Should we do this?!
What should happen
When creating the
command
When executing the
command
15. Event vs Command
Event - Something that has happened!
UserCreatedEvent!
FriendRequestReceivedEvent!
TicketSoldEvent!
Command - Something we want to happened!
CreateUserCommand!
SendFriendRequestCommand!
BuyTicketCommand
16. Event sourcing
All changes recorded as Events!
Order (time) is preserved!
The event log is THE persistent source
17. Aggregates
Unit of consistency!
Example: user, meeting, order, product, game
MeetingCreated
AttendeeAdded A
AttendeeAdded B
AttendeeRemoved A
AttendeeAdded C
Attendees:A
Attendees:A & B
Attendees: B
Attendees: B & C
Event
Stream
27. Playing the game
Player A
Player B
Server
rock
paper
Player B: paper
Player A: rock
Game 123
Game 123
winner: Player B
loser: Player A
CREATED WAITING
GAME WON
GAME TIED
any move
other move
(victory)
other move
(tie)
T