CQRS + EVENT SOURCING Ruslan Gatiyatov 

WHAT IS EVENT SOURCING? Event sourcing is a way of persisting your application's state by storing the history that determines the current state of your application. 

ORM-BASED APPROACH 

EVENT SOURCING APPROACH 

DOMAIN EVENTS Events happen in the past. For example, "the speaker was booked," "the seat was reserved," "the cash was dispensed." Notice how we describe these events using the past tense. Events are immutable. Because events happen in the past, they cannot be changed or undone. However, subsequent events may alter or negate the effects of earlier events. For example, "the reservation was cancelled" is an event that changes the result of an earlier reservation event. Events are one-way messages. Events have a single source (publisher) that publishes the event. One or more recipients (subscribers) may receive events. Typically, events include parameters that provide additional information about the event. For example, "Seat E23 was booked by Alice." In the context of event sourcing, events should describe business intent. For example, "Seat E23 was booked by Alice" describes in business terms what has happened and is more descriptive than, "In the bookings table, the row with key E23 had the name field updated with the value Alice." 

DOMAIN EVENT EXAMPLE 

HISTORY LOG Task created TaskAssignedUserUpdated TaskDescriptionUpdated TaskCompleted TaskDeleted … 

DOMAIN AGGREGATE 

CQRS + EVENT SOURCING 

EVENT HANDLING 

BENEFITS Full history timeline about system, full audit trail Events better describe business intent: AssignedUserToTask, … Performance (events immutable, append-only operations) Simplification. No need to save whole domain aggregate Integration with other subsystems (trigger events, subscribe to events) Flexibility. A set of events can be projected to any desired state. Simple testing 

CONCERNS Requires documentation or good self-documented code Performance of loading of domain-events (domain objects snapshots) Working with versioning (multiple versions of events or aggregates) Complex querying (find all my orders where the total value is greater than $250.”). Solution: CQRS + Event sourcing Infrastructure complexity (Events storage, PUB/SUB, Read model storage etc). Distributed system Eventual consistency Two-phase commits are required. Event save and event trigger should occur together. Skilled team 

MESSAGING CONCERNS Duplicate messages (duplicate message detection, duplicate messages do not have impact) Lost messages Unprocessed messages (failed during message processing). Read message, lock store, process message, remove message. Redundant events - appear with system evolution Events versioning (property changes type, new property was added, existing property was removed). Convert old events either support both types of events.