An Eventful Crypto Storm

Welcome to the post series about my side-project Caterina! The first two chapters introduced the project itself with its motivations and an overview of the adopted “data approach”.

Recap: I want to use Machine Learning to model the price variation of a cryptocurrency in relation to particular categories of events — like a conference about it, a milestone release and so on.

One of the biggest revolutions in software modelling over the past few years has been to look at things from the point of view of what happens in the system, instead than who does it.

Classic modelling starts with describing the entities involved in our context. For instance, we might look at the horse riding world and begin:

There is a Horse object, with the property “name”.
I also identify a Stable object, which has a "surface" property.
Stable is in a "one-to-many" relationship with Horse.

We have identified objects, each of them with certain properties. We would then move on to declare what is accessible of a certain objects and what not (sometimes referred to as its API), and think about the internal behaviour of the object.

The event approach starts instead by focusing on what happens. A flow about a specific situation could evolve like this:

A horse has pooped.
The stable needs to be cleaned: dispatch janitor to clean stable.
Stable has been cleaned.

The difference is quite substantial.

1. We mention what happens, and actually when doing that you can’t avoid talking about involved entities — all participants are quickly exposed. If you order to clean a stable, you must be talking to a janitor.
2. We reason about events happening in a time frame and introduce causalities: a cleaning order is emitted only if a horse has pooped.
3. We can see three different components in our modeling: events (facts already part of history: the horse pooped), policies (a decision taken by someone: the stable needs to be cleaned) and commands (order that trigger a behaviour: dispatch the janitor to clean stable)

We haven’t yet described domain objects and their properties (a horse will still have a name!), but we already have a better idea of how our world is going to work. This modelling approach is called Event Storming (ES).

Probably, the greatest thing about reasoning in events is that events are immutable facts. Facts happened in the past and cannot be changed. Not only this brings our modelling (and implementation) closer to the real world, it also leans towards immutability, so dear to functional programming.

I was lucky enough to attend last year’s Reactive Summit, where Jonas Bonér (CTO and co-founder of Lightbend, creator of Akka) keynoted the conference with his epic talk “How Events Are Reshaping Modern Systems”. He explores the concept at large. If you have time, check the recording below.

The current version of my Event Storming output is depicted in the next image. Being on my own, I used Keynote instead of the canonical stickies on a whiteboard. Colors have the following meanings:

• Orange stickies are events
• Purple stickies represent policies.
• Blue stickies are commands issued based on a policy.
• Yellow overlaying stickies represents Aggregates, which is a DDD term: it indicates the guy that will execute the command and most likely generate a new event.

During my ES iterations, one thing that I initially missed is the difference between internal and external events. As this project is all inside my head and not modelling some real world process, only a few events are external:

• “A new day has come”: the input event that triggers the regular polling of the sources, as explained better in the previous post.
• “A prediction has been formulated”: output event that occurs every time a new crypto event is detected.
• “A failure occurred”: output event in case something goes wrong.

My ES exercise above is far from complete, but it’s a good start. I went through several revisions of event modelling, and I am really thankful to Kelly Baas, a local DDD/ES expert, who gave me invaluable advice. Please enjoy forty seconds of his knowledge in the linked clip!

At this point, it seems that I am dealing with four Aggregates:

• A CryptoEvent guy, who monitors crypto events (such as confererences) and dispatches further internal events (such as “Crypto event annouced. Sorry for the annoying dualism.)
• A Coin dude, who follows over some time the price variation of a coin in relation to a crypto event.
• A Prediction fella, who trains ML models and applies them to new crypto events.
• An Alert chap, whose task is to notify the external world (me) of failures.

The next step is defining a proper set of domain objects, draw an architecture and make implementation choices!

Fabio Tiriticco - Medium