Tagged: event sourcing
Recent Talks with Big Effect on My Development
I have seen many, many development talks, actually an embarrassing amount. There have been many talks that have altered how I develop or think about development. Actually, since 2013, some talks have caused a major shift in how I think about full stack development, my mind has been in a major evolutionary cycle.
CQRS and Event Sourcing
My thought process about full stack development started down a new path when I attended Code on the Beach 2013. I watched a talk by Greg Young that included Event Sourcing, mind ignited.
Greg Young – Polyglot Data – Code on the Beach 2013
He actually followed this up at Code on the Beach 2014 with a talk on CQRS and Event Sourcing.
Reactive Functional Programming
Then I was introduced to React.js and I experience a fundamental paradigm shift in how I believed application UIs should be built and began exploring reactive functional programming. I watched a talk by Pete Hunt where he introduced the design decisions behind React, mind blown.
Pete Hunt – React, Rethinking Best Practices – JSConf Asia 2013
Stream Processing
Then my thoughts on how to manage data flow through my applications was significantly altered. I watched a talk by Martin Kleppmann that promoted subscribe/notify models and stream processing and I learned more about databases than any talk before it, mind reconfigured.
Martin Kleppmann – Turning the database inside-out with Apache Samza – Strange Loop 2014
Immutable Data Structures
Then my thoughts on immutable state was refined and I went in search of knowledge on immutable data structures and their uses. I watched a talk by Lee Bryon on immutable state, mind rebuilt.
Lee Bryon – Immutable Data in React – React.js Conf 2015
Conclusion
I have been doing professional application development since 2000. There was a lot burned into my mind in terms of development, but these talks where able to cut through the internal program of my mind to teach this old dog some new tricks. The funny thing is all of these talks are based on old concepts from computer science and our profession that I never had the opportunity of learning.
The point is, keep learning and don’t accept best practices as the only or best truth.
Have You Heard about Event Sourcing?
I cut my teeth in programming in the BASIC language on a computer that had a tape recorder as the persistent memory store (if you don’t know what a tape recorder is Google it). From there I transitioned to VBA and VBScript which wasn’t a stretch because it was all procedural, chaining a bunch of instructions to make the computer do what I want.
During my VB scripting days I was exposed to ASP and relational databases through Access then SQL Server. Cobb’s third normal form was not that much of a stretch for me to grasp. When .Net 1.0 came along as soon as it was released I jumped from ASP to ASP.NET and I took all of my procedural habits along with me to VisualBasic.NET.
Then as I barely got started with .Net I heard all the buzz around C# and object orientation and I just didn’t get it. I tried to force my procedural understanding into an OOP hole. In ASP I would create separate scripts for little pieces of functionality I wanted to reuse. I thought I was getting the same benefit of reuse and object composition that everyone was raving about with C#. How little I knew.
Today I find myself in the same boat trying to understand Event Sourcing. I am trying to fit Event Sourcing into a relational hole, but this time I won’t spend a couple years just doing it absolutely wrong. My boss asked me to talk about Event Sourcing and I took it as an opportunity to learn more about it, even though I will likely never give the talk. I did quite a bit of research and this is more of a post on where you can find some useful info.
Everyone starts with Wikipedia definitions, not sure why, but here is Event Sourcing according to Wikipedia…wait, there isn’t a Wikipedia page for it (as of 8/26/2013). Even Martin Fowler has Event Sourcing as a Work-in-Progress on his EAA page on the subject. So why the hell are we talking about it?
Event sourcing is in production on some of the most data intensive systems on the planet. People way smarter than me advocate it. Also, sometimes it’s nice to be on the cutting edge of a movement as it forces you to innovate.
Event Sourcing is a data persistence technique that focuses on capturing the state of an application overtime. The states are captured in an event object and the objects are stored in sequential order according to the time that the state changed. Once the state is captured, it can’t be changed or undone, it is immutable. To correct a mistaken state change you have to issue a compensating state change to correct it. So, your persisted state is the gospel, if it was stored you can trust that it is true and wasn’t tampered with (outside of some malicious change to mess with you).
OK, I’m not sure about you, but when I learned this it blew my mind. The idea of persisting the entire history of the state of my application was a red or green pill moment for me. On one hand it seemed terribly inefficient to store the state of every object in my application especially since most of the discussions is about using NoSQL DB’s. How could you possibly query this data easily and what benefit does it get me? Then I learned about the ease of data recovery and production incident research and being able to replay events that happen in production last month on my local box today…what!
Then I had an epiphany. I have source control for my code, took me a little to get comfortable with it and it provided a lot of benefits for me and hopefully for you too. Event Sourcing is something a little like source control for application state. Actually, SVN is an example of Event Sourcing used in my environment at work today. So, this understanding made it a practical solution to me, but I was still unclear on real world usage and what scenarios would benefit most from Event Sourcing.
Being in the financial industry auditing is a big deal and Event Sourcing could provide an instant audit log of every transaction we record. Yet, the whole logging of every event seemed a little overkill. I won’t try to persuade you either way or actually try to explain it to you as I couldn’t do the subject justice, but I decided it was too much for my current projects. Actually, a couple videos by one of the originators of CQRS (another concept that I am researching) has a lot to offer on the subject of event sourcing. Its buried in these references, but its all related and in my opinion all fascinating. Especially, if you are into broadening your coding horizons.
Decoupled Logic 