Slide 1

Slide 1 text

The fallacy of state recovery from event storage speaker: Jordi Martínez

Slide 2

Slide 2 text

Who am I? š Senior Software Engineer and Architect, currently at Dorna Sports š You may follow me at Twitter (@jmquarck), or my recent blog How Possible.

Slide 3

Slide 3 text

Events š Events are representations of facts.

Slide 4

Slide 4 text

Events š Events are representations of facts. š Facts are pieces of external reality. We may say facts are the atoms of truth.

Slide 5

Slide 5 text

Example: subscriptions š A UserSubscribed Event representing the fact of a particular User fulfilling the subscription process in our UI.

Slide 6

Slide 6 text

Example: subscriptions š A UserSubscribed Event representing the fact of a particular User fulfilling the subscription process in our UI. š These UserSubscribed events might trigger a Command to write a new line in a Schedule, so that a fair warning email would be sent to that User once the current subscription period is reaching its last day. š Eventually a Renew Subscription Command would run once the current subscription is over and the User should be charged for a new subscription period.

Slide 7

Slide 7 text

Example: subscriptions š Actually, this is an example of how Events can trigger actions not only in the immediate present, but also in the farther future.

Slide 8

Slide 8 text

State š And, what about State?

Slide 9

Slide 9 text

Local state š We may define a Local State as a summary of the values of some properties of Entities, or Aggregates, inside a given bounded context at any particular moment in time. š There is no restriction on the list of properties to include in the definition of State, as well as on the calculations we might run on them as part of the summary.

Slide 10

Slide 10 text

Example: inventory š The Inventory, defined as the economic value of all the Items we own, at any particular date.

Slide 11

Slide 11 text

Example: inventory š For instance, we may talk about the local state Inventory at the 31d of December, 2017. š This state would look like a catalogue of all the Items we owned that day with at least 1 unit of stock, with their economic value at that moment (FIFO, Weighted Average Price), in a particular currency.

Slide 12

Slide 12 text

Example: inventory Item Units in stock Mean Acquisition Price Value AB457 15 30,25€ 15x30,25€ = 453,75€ GL300-B 22 4,76€ 22x4,76€ = 104,72€ TR200 108 17,32€ 108x17,32€ = 1.870,56€ Inventory at 31d, December 2017: 2.429,03€

Slide 13

Slide 13 text

Example: inventory Item Units in stock Mean Acquisition Price Value AB457 15 30,25€ 453,75€ GL300-B 22 4,76€ 104,72€ TR200 108 17,32€ 1.870,56€ Inventory at 31d, December 2017: 2.429,03€ A detailed view of the State

Slide 14

Slide 14 text

Example: inventory Item Units in stock Mean Acquisition Price Value AB457 15 30,25€ 453,75€ GL300-B 22 4,76€ 104,72€ TR200 108 17,32€ 1.870,56€ Inventory at 31d, December 2017: 2.429,03€ A summarised view of the State: State summarised by an indicator

Slide 15

Slide 15 text

Local state š States are not snapshots, because the state stays the same for as long a period of time as the values of the properties do not change.

Slide 16

Slide 16 text

Example: Customer state š Despite Local States, which spread over one bounded context, could we define a Global State spreading throughout several bounded contexts of, say, Customers? š Let’s try with the asking some particularly interesting questions.

Slide 17

Slide 17 text

Example: Customer state š Is she profitable (at this particular moment in time)? š This means whether this particular Customer yield more revenue than the total cost we had to spend with her up to this moment.

Slide 18

Slide 18 text

Example: Customer state š Is she active (at this particular moment in time)? š This means whether she completed at least one of the actions we decided are necessary for any Customer to be labelled as Active.

Slide 19

Slide 19 text

Example: Customer state š Is she in debt (at this particular moment in time)? š This means whether she has standing out bills, no matter their expiration date. š Or, are we in debt with her (at this particular moment in time)? š This means whether there are item delivery pending from our side.

Slide 20

Slide 20 text

State recovery š Are those States, and any others alike, recoverable from an Event storage? š For instance, in the example of Inventory, is it possible to rewind our Event Storage to the farthest moment in the past, and replay all the events related to Inventory from then on to the 31d of December, 2017?

Slide 21

Slide 21 text

State recovery š Clearly yes, it is! š Provided every UnitReceived and UnitDispatched events were stored there, for every Item in the Inventory. š Easy, right?

Slide 22

Slide 22 text

Local state recovery pitfalls š Well, not so, because Item events should have been implemented before the first unit of stock ever arrived to our ownership (either by purchase, by us producing them, or from the company founders). š Hardly likely, since Events are far more recent in inventory software implementations than stock handling.

Slide 23

Slide 23 text

Local state recovery pitfalls š We might work around this unfortunate fact by introducing a special InitialStateEvent, or similar, representing the actual Inventory at a particular date of our convenience, so that Inventory recovery (rewind, replay) would be possible from that particular instant onwards. š To make its magic, this InitialStateEvent should be the very first one in the Event storage.

Slide 24

Slide 24 text

Local state recovery pitfalls š And, what if some units had been lost, or stolen, from the warehouse and we found it out weeks later? š Companies are used to these corrections and carry on manual inventories regularly, as well as other more sophisticated operations to ensure that the inventory value is right. However, this corrections keep their date, hence the wrong State often stays as it was.

Slide 25

Slide 25 text

The fallacy exposed š So, the fundamental truth is worse: States stand for a representation of reality as we knew it was at a particular moment in time, but not what we now know it was at the same particular moment in time.

Slide 26

Slide 26 text

Options to cut the Gordian knot š Could we imagine ways to circumvent the fallacy? š I bring two suggestions: š Retroactive fact representation by dispatching bespoke corrective Events. š Event transformation on replay time.

Slide 27

Slide 27 text

Tactic 1: retroactive recovery š This tactic stands for storing brand-new Events to represent past facts we know now, but that were not known at the time. š In other words, we are dispatching Events now that represent facts in the past so that past States may be recoverable now.

Slide 28

Slide 28 text

Tactic 1: retroactive recovery š From an operative point of view, for this recovery to work State calculation procedure must spread throughout the whole Event storage, no matter what moment in the past the State pinpoints to.

Slide 29

Slide 29 text

Tactic 1: retroactive recovery š Should we store these Events in the same Event storage, or, to keep this latter's purity, store them in a separated Event storage (a Complimentary, Retrospective Event Storage)? š Actually, this separated event storage would make that false retrospective events operatively easier to pick when needed, since this would have likely a far smaller size.

Slide 30

Slide 30 text

Tactic 2: event transformation on replay š Since we are recovering States, not Events, we might plug in an intermediary service between the Event storage and the State producer which transforms their payload to either calculate new properties, or modify the values of others. Some call this operation upcasting, for it was invented to handle Event schema evolution. š We might even complicate further this transformation with combination of several Events in one via the common algebra operations (union, intersection, disjunction, etc.)

Slide 31

Slide 31 text

TL;TR š Events represent facts. š States summarise knowledge of the Domain in a particular moment in time, by a selected gathering of Events from the Event storage. š But State production from Events can only represent the knowledge we stored until that particular moment in time. Further facts relevant to that State might arise later on, so that we should either abandon States, for misleading, or add this new information to the one provided by the Events in the store somehow. š We have seen two possible tactics to achieve this: dispatch of corrective Events, and transformation after recovery.

Slide 32

Slide 32 text

Thanks! š I am eager to keep talking about this now, and further. š Thanks for your attention, patience, and feedback.