"Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes"
Reference 3: Introducing Event Sourcing @ MSDN Patterns & Practices
- 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."
Event Sourcing Basics · EventStore/EventStore Wiki @ GitHub
All events should be represented as verbs in the past tense such as CustomerRelocated, CargoShipped, or InventoryLossageRecorded.
It is not possible as previously jump into the time machine and say that an event never happened (eg: delete a previous event). As such it is necessary to model a delete explicitly as a new transaction...(that is un-doing effects of one that needs to be removed)
Hottest 'event-sourcing' Answers - Stack Overflow
CQRS Info Command Query Responsibility Segregation
CQRS Info Command Query Responsibility Segregation
No comments:
Post a Comment