Event Sourcing for the rest of us


Event Sourcing, The CommandBus or Repository of 2017? Surly you’ve heard about it, but what exactly is it?

Event sourcing can be described as storing the events that happened in your system in the order they happened, in some kind of store. These events are then replayed to recreate state in your system, rather than just having a single row in a table, using event sourcing, you have a full history of actions that happened in your system, and how your state got to the given point that it is in.

Let’s take an example of a single entity, and what’s involved with working with that using Event Sourcing. Please note that this code is strictly shown as an example on what is involved with working with Event Sourced systems on a basic level.

First off we need our EventStore, this needs to support retrieving and saving events for a given Aggregate, an Aggregate is just an Entity that events are triggered through.

It’s up to you where these events are stored, it could be in a row in a table in a relational database, a document store like MongoDB.

There is a database designed for storing and processing event, GetEventStore, which is quite powerful and makes a lot of decisions for you.

Up next we need an event, let’s say our system needs to register a Member.

So, using event sourcing, our state is built up from events, so naturally, our entities will only deal with events.

You’ll notice that there are five methods inside this class:

  • register – Gets called by your application code to register a member, this fires an event internally to the entity.
  • raise – Raise or fire an event.
  • apply – Takes an event, and applies it to the entity, building its internal state.
  • releaseEvents – Returns you an array of all the events that were raised internally in your entity, and clears the pendingEvents
  • rebuildFromEvents – Given an array of events, apply them to the entity to recreate the current state, or state up into a given point in time.

You would most likely extract this functionality to a trait, or a base class like EventSourcedEntity.

Last but not least, let’s have a repository so we have a way to find and save our Member entities, this will work with the help of our event store.

Do note that every time you call find, you will be rebuilding your entity from all your events, which could get quite slow when you have lots of events, in the next post we’ll go through a solution for this, called Projections.

Let’s hope that seeing some code has helped you grasp some of the moving parts of event sourcing, stay tuned for more posts on the topic, and a deeper explanation into how a system scales using event sourcing.

Inventing the universe? Microframeworks


Recently for a side project, I figured I would give the latest version of Slim Framework a shot as I was building a small application where I didn’t think I would need many ‘full stack’ framework features. For most projects, I generally reach for Laravel.

The first thing I came up against was that I wanted a templating engine, Blade? nope, we’re using slim! So off I went and pulled in the Slim-Twig package, great, I have templates. I was quite familiar with Twig and was quite simple to get setup.

My next job was fetching some data from an XML feed and mapping it to my own entities, it was rather slow to do this every page load so caching to the rescue! I reached for Doctrine Cache and just used the filesystem driver, great success! Next?

I kept developing, then got sick of having to manually wire up my container services, this is a somewhat controversial this view but I like the auto wiring feature in the Laravel container, so I ventured out and ended up pulling in PHP-DI Slim Bridge so that I could have some auto-wiring!

The next hurdle was authentication, I had a bit of a unique requirement where I was authenticating to an LDAP server, but to check if the credentials are valid, I need to try to ‘bind’ to the server, which is the term used for authenticating to an LDAP server. Authenticate to authenticate you say? Yup.

For this I ended up writing a light wrapper over Zend Authentication, in this case, I feel like this was better suited to the situation, and not trying to shoehorn my LDAP authentication requirement into the Laravel’s built-in authentication.

I had built a custom ‘framework’ of sorts with components from everywhere! Great you think, small decoupled libraries are fantastic so we can build our own small application from the ground up.

Truth be told looking back at the experience, even these simple things that I needed, (Caching, Templates, Authentication) are already solved for me in Laravel, out of the box, with almost zero configuration, ‘it just works’.

I’m not dismissing micro frameworks, I just feel for this use, and many other uses, the time saving and developer productivity gains with using a full stack framework outweighs lots of manual configuration, picking what library to use and putting it all together.

While working on this, another thing crossed my mind. What if this wasn’t a side project? What if it was some huge production application, the cognitive overhead of trying to keep all these libraries and components in your head would be quite overwhelming, and imagine how long it would take to get another developer up to speed? Full stack frameworks solve the already solved problems for us, so why reinvent the universe?

You can find the code for the project on my Github, http://www.github.com/samgreenwood/nodemap

And if you’re interested in long-range wireless networks and happen to live in Adelaide, Australia, come check our Air-Stream Wireless