Monoidal Event Sourcing
I Could not sleep… 3am and this idea…
Event sourcing is about fold but there is no monoid around !
What’s a monoid ?
First, for those that didn’t had a chance to see Cyrille Martaire’s fabulous explanation with beer glasses, or read the great series of post on F# for fun and profit, here is a quick recap:
We need a set.
Let’s take a simple one, positive integers.
And an operation, let say + which takes two positive integers.
It returns… a positive integer. The operation is said to be closed on the set.
Something interesting is that 3 + 8 + 2 = 13 = (3 + 8) + 2 = 3 + (8 + 2).
This is associativity: (x + y) + z = x + (y + z)
Le last interesting thing is 0, the neutral element:
x + 0 = 0 + x = x
(N,+,0) is a monoid.
Let say it again:
(S, *, ø) is a monoid if
- * is closed on S (* : S –> S > S)
- * is associative ( (x * y) * z = x * (y * z) )
- ø is the neutral element of * ( x * ø = ø * x = x )
warning: it doesn’t need to be commutative so x * y can be different from y * x !
Some famous monoids:
(int, +, 0)
(int, *, 1)
(lists, concat, empty list)
(strings, concat, empty string)
…
The link with Event Sourcing
Event sourcing is based on an application function apply : State –> Event –> State, which returns the new state based on previous state and an event.
Current state is then:
fold apply emptyState events
(for those using C# Linq, fold is the same as .Aggregate)
Which is great because higher level functions and all…
But fold is event more powerful with monoids ! For integers, fold is called sum, and the cool thing is that it’s associative !
With a monoid you can fold subsets, then combine them together after (still in the right order). This is what give the full power of map reduce: move code to the data. Combine in place, then combine results. As long as you have monoids, it works.
But apply will not be part of a monoid. It’s not closed on a set.
To make it closed on a set it should have the following signature:
apply: State –> State –> State, so we should maybe rename the function combine.
Let’s dream
Let’s imagine we have a combine operation closed on State.
Now, event sourcing goes from:
decide: Command –> State –> Event list
apply: State –> Event –> State
to:
decide: Command –> State –> Event list
convert: Event –> State
combine: State –> State –> State
the previous apply function is then just:
apply state event = combine state (convert event)
and fold distribution gives:
fold apply emptyState events = fold combine emptyState (map convert events)
(where map applies the convert fonction to each item of the events list, as does .Select in Linq)
The great advantage here is that we map then fold which is another name for reduce !
Application of events can be done in parallel by chuncks and then combined !
Is it just a dream ?
Surely not.
Most of the tricky decisions have been taken in the decide function which didn’t change. The apply function usually just set state members to values present in the event, or increment/decrement values, or add items to a list… No business decision is taken in the apply function, and most of the primitive types in state members are already monoids under there usual operations…
And a group (tuple, list..) of monoid is also a monoid under a simple composition:
if (N1,*,n1) and (N2,¤,n2) are monoids then N1 * N2 is a monoid with an operator <*> ( (x1,x2) <*> (y1,y2) = (x1*y1, x2¤y2)) and a neutral element (n1,n2)…
To view it more easily, the convert fonction converts an event to a Delta, a difference of the State.
Those delta can then be aggregated/folded to make a bigger delta.
It can then be applied to a initial value to get the result !
The idea seams quite interesting and I never read anything about this.. If anyone knows prior study of the subject, I’m interested.
Next time we’ll see how to make monoids for some common patterns we can find in the apply function, to use them in the convert function.