All Posts assertfail

View the Blog on GitHub wallymathieu

Event sourcing and in memory database

03 Mar 2015

Trying out OrigoDb, I found it interresting to try out a more raw file store approach and NEvent Store. Why the connection Event Sourcing and In memory databse? Mostly because I tried out OrigoDb first. In memory database feels like a nice fit for Event Sourcing (since the log that can restore the database can be persisted in an append only manner).

Many of us have heard or read Martin Fowlers Event Sourcing. He mentions in memory databases in the article as well.

OrigoDb is a bit easier to setup compared to NEvent store. NEvent store is more mature. I like that you don’t need to inherit from a base class in NEvent Store. It does mostly what it says it does: Persists events. This means that it if you want to use it for an in memory situation you probably should make the objects readonly. The OrigoDb approach of using inheritance gives you fewer lines of code (since you don’t get command and handler types). NEvent store is more talkative and requires more code to handle events.

Since OrigoDb assumes that you want help with making absolutely sure that your in memory data is not corrupted by a assignment of on an object you need to interact with the it in a slightly different manner (from OrigoDb CustomerDataTests ):

        public void CanGetCustomerByFirstname()
            var customers = _engine.Execute(m=>
                .Where(c => c.Firstname == "Steve")
            Assert.AreEqual(3, customers.Count);

Storing your events in an append manner on the filesystem is the easiest approach. Use of readonly objects simplifies things (easier to make sure that the data does not diverge). Perhaps a usecase for With?

The problem with using the filesystem directly is that it’s not ACID. However, you get ACID using OrigoDb.


  • db
  • Comments or errors? Fork post and do a pull request on github