Under the hood www.miljoparkering.se is, admittedly, quite overdesigned.
The web site, in its current form, is very simple: People sign up. They then choose the streets they want reminders for. It’s also possible for them to change their e-mail address. Every night there’s a recurring job that goes through all the user profiles, matches them with street cleaning tasks for the day, and then send out reminders to the users that has these streets selected. The site could have been made easily in a short time with a simple relational database, simple data access layer and some CRUD code.
For the last year or so, however, the Command Query Responsibility Segregation (CQRS) principle and Event Sourcing has been surging up the trend curve. It’s hard get around if you’re interested in system design. Many people talk about it, it’s discussed on community meetings. We actually considered CQRS when we had to make initial technology choices for Mikz.com, the daytime project I’m currently working on. But CQRS+EventSourcing is quite different than the classic de-facto enterprise system design, the n-layered design.
In a n-layered design, you’ll typically see at least three layers, UI, domain logic and database access. Depending on your flavor, you might have more layers, and the data access layer might / might not be implemented with and ORM framework such as nHibernate. After changes changes are made to the domain model, the current state of the model is persisted into the database. When you need to get information from the system, the same layers are used to query for the current state.
In CQRS, you don’t use the same model for both updating and for querying. There’s a model that facilitates safe and structured changes to the domain objects (through the use of “void” commands). And there’s a model for querying the system. The first model may be relatively slow to work with, but that’s ok because we need to validate the information and ensure that the changes are made correctly, and we maybe even have notify other systems that a change has occurred. The read model, however, generally needs to be fast since most often, for each update you make to a system, there are many reads.
Creating a system based on CQRS can be done without Event Sourcing. But Event Sourcing has some advantages, that doesn’t come naturally from a system, that just contains the current state, such as getting answers to new questions from a system that is already running. This makes the Event Sourcing concept very interesting. Also, data from a system based on Event Sourcing is quite different: current state is not persisted in the data store. Instead, all the events that occurred in the system lifetime are saved, from which current state of any domain object can be extracted!
With many years of experience with development of n-layered systems, Björn and I agreed that it was about time to get our hands dirty with CQRS and Event Sourcing. We wanted to gain real life experience, and thereby get a bit of distance to theoretical discussions, some of which where a bit too glorifying, and instead be able to make choices on behalf of our enterprise customers based on real experience. This is the reason behind the overdesign of www.miljoparkering.se – it’s by design.
As of writing this, with version 1.0 of the system, we are aware that this is only the start of our experience with CQRS+EventSourcing. Our professional experience tells us that we need to experience at least (1) an upgrade iteration, as well as at some point (2) facing a previous design choice, that has to be refactored/rectified/expanded. I will blog when we reach those experiences.