khtan (51) [Avatar] Offline
#1
Thanks for the next installment. Here are some feedback :

1) 10.2.2 Persisting events
"So, events are simple, flat data objects that capture data about an event."
Circular statement unless the latter event has some specific meaning that
is not articulated.

2) 10.2.1 Representing events
"since it involves less operational overhead. If the business-critical"
Lines after this are missing.

3) 10.2.4 An interlude on pattern matching
Icon for Button4 not drawn in Listing 10.4

4) 10.2.5 Representing state transitions
The signature "give me a state and an event and I'll compute a new state"
could also be written as :
event -> state -> state ----(b) instead of
state -> event -> state ----(a)

The difference is that (a) starts and ends in a state while (b) starts with an event, and ends in a state
Is this just a syntax nicety or would using signature (b) cause problems later on?

Thanks,
Enrico Buonanno (69) [Avatar] Offline
#2
Thanks for the pointers; 1-3 will be addressed in the next rendering

1) "So, events are simple, flat data objects that capture data about an event."

What I really meant is: "event-classes are simple, flat data objects that capture data about an event-real-thing-that-happened"

4) 10.2.5 Representing state transitions
The signature "give me a state and an event and I'll compute a new state"
could also be written as :
event -> state -> state ----(b) instead of
state -> event -> state ----(a)

Of course, both signatures are possible. But if you think about it, a state transition is the reducer function of a fold: the state of an entity is a fold over the list/stream of events that happened, with the initial state of the entity when it was created as accumulator. The convention is that the accumulator is the first parameter to the reducer function.
ekennedy6334 (2) [Avatar] Offline
#3
Love this book!!

Looks like just before 10.2.3 some text was cut off.

Thanks!
Thorsten Deinert (7) [Avatar] Offline
#4
I enjoyed reading chapter 10, especially because an event-based solution is what I need to make the history of orders in an internal booking system obvoius.


You're using bank accounts and transfers as an example in this chapter. Thinking about it, that seems to be the perfect fit for an event-based system: Double-entry bookkeping is just smart way to record events, isn't it? And balancing is transferring them into a current state...

"Replaying" the history to get the current state of a single account is well explained and straight forward. What I wander is, how would I query all accounts that are in some specific state in an event-based database? For example, to process reminders, etc.?