One day (when I know what I’m talking about) I shall do a piece on Event Sourcing. It seems that there is a barrier of entry to newcomers; due to a number of inevitably-linked practices around ES (e.g. DDD, CQRS) already having flexible implementations, meaning that your ES probably won’t look or work quite like everybody else’s. It’s probably why there are a lot of articles encouraging you to use it, but none teaching you how (as is also the case with this post).
Event Sourcing (using an event store to source a system of record) will invariably draw comparisons with using an RDBMS, because that is most likely what you are used to and already using, but it has such different strengths that it should really be considered on own merit. It doesn’t do anything ‘better’ than Sql Server. It is part of a solution which is made up from a suite of tools and practices that do things differently. There is no straightforward comparison.
At the heart of Event Sourcing is an event store. Once upon a time this was probably implemented to provide a message queue between loosely coupled services. But it has more potential than that – depending on the features that have been built in. One that I am particularly enjoying tinkering with is EventStore (http://eventstore.org) which lends itself well to Event Sourcing with it’s (claimed) support for millions of streams, built-in projections, and simple but flexible subscriptions. Plus it supports the widely understood Atom standard, so libraries will exist for most languages to consume its event feeds.
It is easy to set up and start using and you can quickly prove the concept of Event Sourcing, and appreciate the benefits.
I am looking forward to putting together some demos and tutorials, assuming my experiences remain as positive as they’ve been so far.
More to come.
Recent Comments