The value of Event Sourcing

I honestly feel obliged to write this article because I feel that most developers think about Event Sourcing as only another PoEAA (Pattern of Enterprise Application Architecture). Maybe reserved to software models which have a certain level of complexity or at least they need to look like they do so that the time and cost is justified. Event Sourcing is a lot more than just an architectural choice. Its utmost value is in the data it preserves.

As aforementioned, essentially, most of us think of Event Sourcing as just a pattern of enterprise application development. I don't agree with this description, at least not by itself because Event Sourcing can, and is, applied to several types of applications, enterprise and otherwise. The call logs on our mobile phones are persisted as events as much as most customer transactions are within a CRM (Customer Relations Management) application.

As Martin Fowler wrote in the preamble of this article, Event Sourcing - "capture all changes to an application state as a sequence of events". From this description, we can extract the real value of Event Sourcing, which to me is the captured data in form of events. I find that it is natural for us human beings to form logic out of events because our lives are simply a series of events. Our behaviour, our thoughts, our incidents, our work, our dreams and everything else is an event. When something happens, that's an event. So why are we not persisting this information since we already have it?

One of the most valuable resources of our time is data. Data is indispensable to most if not all industries. Data is collected, sold and purchased, bartered and negotiated. But data is a lot more valuable when it's in form of events because unlike say a simple mailing list (which, by the way, you should subscribe to 😉), event sourced data is full of information we don't even know we'll need but we can safely assume that we will. From stored events, we can extract behaviour, patterns, habits and a lot more.

Since things happen, store the fact that they did. Don't throw this information away because even today there's an application where this information is useful and tomorrow, well, there will be a lot more.

Event Sourcing can be applied to any domain in which things occur. This can be anything from an IC (Integrated Circuit) in your coffee maker to an ERP (Enterprise Resource Planning) system. If things (events) occur then you can store that fact.

Does this mean that we should apply Event Sourcing to every application? The brief answer is Yes, we should. The longer answer is; apply Event Sourcing whenever you afford to or, even better, think about it in reverse. When should we not apply Event Sourcing? The answer is even simpler; don't apply Event Sourcing when you afford to lose the data your application should store but is throwing away. What you don't store today will not be available tomorrow and I'm sure that you will need all of it tomorrow.

I believe that the two primary reasons why Event Sourcing is not applied as much as it should be are due to; one, lack of knowledge of how to apply it in an integrated system and two, the additional work involved in applying this pattern. None of these reasons justifies the loss of information and both of them can be easily mitigated. Knowledge is available and most of the additional work involved can be reduced and almost eliminated by code file generators and infrastructure frameworks. Even if you create both the generators and the framework yourself on your own, these will be reused over and over again. In most part, it's a one-time investment.

Planning and applying Event Sourcing is relatively simple. In my opinion, the modelling of an event sourced domain is far simpler than that of say; a Domain Driven Design (by itself), not to mention a Data Driven Design 🤣. The reason is that if we think about any given problem in forms of events, we are then very close to the real-life application of the said problem. It is easier to think about software through the lens of the real life domain than an algorithm or some other form of process logic.

Let's momentarily ignore the big data folks at Alphabet and Facebook and think of how we can benefit from our event sourced data. The first application that comes to mind is Machine Learning which has one primary requirement; data.

We've already established that event sourced data is by far more valuable than any other data which might be out of context. It's also a fact that Machine Learning attempts to, and most of the time successfully manages, construct algorithms that make predictions from data. The data captured within a well-planned event sourced model replicates the real-life process a human or any entity follows. Feeding this accurate data into a Machine Learning algorithm(s) will result in extremely useful predictions.

We don't even need to imagine a scenario were to apply this, as many already exist, but take this a few steps further and connect every input device to an event store; the result can be used by numerous machine thought applications such as health and psychological diagnostics. Connect your favourite IDE to an event store and you might even end up with automatically developed software applications.

Machine Learning is in fact quite basic, yet incredibly accurate and powerful. The only missing link is the data we throw away every day by using damning software models and persistence architectures. This waste of information is the cause of delay for several groundbreaking innovations, cures and overall life improvement.

As I'm writing this post, YouTube is auto-playing music and for some reason, it's playing some relaxing Jazz & Bossa Nova, a genre I would never choose but one which fits perfectly with the work at hand. Thank you YouTube, I appreciate the selection. The machine thought music selection is great, but, I'm sure we can find more useful applications for Machine Learning. Let's do out part and start with not destroying vital information because tomorrow, next week or next year someone (or something, hint hint Elon Musk) will make great use of this data.

I really never liked the term Artificial Intelligence because what's artificial about say for example Autonomous Cars? The car is physical, it drives by itself, as in, it physically and not artificially produces kinetic energy from a different energy source and a software application guides it to a destination along a certain route.

Just a few years ago, we would refer to Speech Recognition as Artificial Intelligence, which made sense at the time because the assistance and support provided by those extremely stupid and annoying IVR (Interactive Voice Response) systems were artificial. Now, a lot of us use Speech Recognition without even thinking about it. I utter "Okay Google" to my phone's microphone more than I say "Hi" to real people on any given day. I don't think of this technology as Artificial Intelligence and most probably you don't either. I think the consensus is that when a Machine Learning project is still in its ambitious phase we refer to it as Artificial Intelligence until it becomes a part of our daily lives when then it's just, well, intelligence.

Machine thought applications from captured events' data is not artificial at all. I mean the CIA (Central Intelligence Agency) uses Machine Learning algorithms every day. Should we start calling it the CAIA (Central Artificial Intelligence Agency)? 😊

The main points I wanted to put across in this article are: