Archive for the ‘CQRS’ category

When should you use CQRS or event sourcing?

February 28th, 2013

I am currently in the process of helping migrate our current legacy application to an event sourced system, also known as a CQRS (Command Query Responsibility Segregation) system.  We have had some pitfalls for sure and I wanted to outline some of that in this post.  We went with the LOKAD system which can be found here: Lokad Project.  It has hooks into the Microsoft Azure cloud solution so it was a great starter for us to get rolling with that.

The system actually ran fine for quite a while just getting data in and out, things were working perfectly until we decided to throw a lot of commands at the server and see how that processes that.  Rinat Abdullin, the creator of LOKAD outlines that here: Lokad Event Store is slow, we were using the azure blob storage and all that serialization/deserialization causes some serious performance issues when you multiply that by n number of times.  We have moved to the Event Store written by Greg Young found here: Event Store.  This speeds up the writes of the LOKAD system when it comes to the events but still didn’t solve the problem of our read models and how this system likes to make these projections.

If you have been following some of my blog posts in the past, you would know that I have done some research with couchdb, well a co-worker at my work place has been doing a lot of research into Couchbase which leverages couchdb with memcache.  I already liked it cause they used couchdb and I knew how performant that was, what I didn’t know was that it caches a lot of the calls and data, so its in memory and extremely performant.  Our plan is to replace our current readmodels being stored in the azure blobs, which can get quite large, so the serialization/deserialization in some situations can bring performance down to a crawl, to be stored in couchbase.

Anyway, back to my original question, When should you use CQRS or Event Sourcing?  My advice would be to analyze your companies requirements and ask yourself if a system like this would truly give you a reward worth the investment?  My personal opinion is for most business applications it is not needed or necessary to track the intentions or actions on data.  There are some business use cases that I could see it being good for, take banking for instance, its critical to know how the money got from point A to B, or accounting, again mission critical.  Greg Young says he does not like Case Studies, that they are too gimmicky, read his post here: Greg Young Case Studies So I still cannot find a really good case study but I did come across this guys blog post which pretty much sums my overall views on the pattern: A Year in review with cqrs he pretty much came to the conclusion that he doesn’t use the pattern for its intent and a key/value store would have done the job just as well.

There are people out there that think most all applications should be written with this pattern, all I am saying is look at what your needs are and make a judgment call there. I am potentially looking at making a mobile version of a website I worked on with a friend, there is no way I would implement an event sourced system in this situation, it won’t make sense and my client is not going to pay for it, you have to factor in the time it takes to model out the domains and figure out what actions are to be performed on the data.

If you are currently implementing a system like this, I welcome your comments, feel free to leave em, you won’t hurt my feelings. I too am trying to see the real value in a system like this.

NCQRS Fork on GitHub

January 23rd, 2012

I noticed that the NCQRS project was missing a CouchDB event store example, so I created a project in the master NCQRS project that shows how you can hook into it using CouchDB, check out my fork at the address below.

Is CQRS a fad?

January 17th, 2012

If you follow a lot of the .net development world, there is a new term being thrown around a lot called CQRS, it stands for Command and Query Responsibility Segregation.  There are a few key players in this up and coming pattern of development if you want to know more, I have provided links below to some of the guys I have read up on.  At the heart of this pattern is the idea of event sourcing, or the ability to create a series of commands and events that will create your objects in your system.  This is the key feature of the pattern in my opinion and I think this is why there is an argument that the pattern or the little community that is growing is considered a fad.

As for the rest of the pattern, if you look into it much, the community will tell you that the bits and pieces are “An implementation detail” and not really a big deal.  I think this is where the rub comes in for a lot of folks looking into using this pattern for their next distributed project.  When it all boils down to it, what are you trying to get accomplished with a distributed system?  You are trying to get data from point A to point B.  I guess if you want to stick a name on it, then CQRS could be one, or we could just call it a distributed system, doesn’t really matter to me.  I know that the java and ruby guys have been doing systems like this for quite a while now and they do not have a term for it besides “distributed”.  Anyways, just thought I would throw this out there for anybody doing research into writing their next distributed app, references below.

Greg Young – Seems to be go to guy for CQRS
Rinat Abdullin – Another guy right on par with Greg
Udi Dahan – the creator of NServiceBus
Mark Nijhof
Jonathan Oliver – Creator of a very good Event Store for a variety of Durable Storage mechanisms.