Overview

The aim of this framework is to provide Command Query Responsibility Segregation (CQRS) possibilities and a simple event sourcing system for web applications build on top of rails. Simply spoken, CQRS is a pattern for using two models for your application, one for changing your model (commands) and another for reading it (query). Martin Fowler provides a good overview.¹ Event sourcing extends this pattern further, by storing all the changes to the application state as a series of events.² The approach to event sourcing in rails-disco is different in the way that only valid changes to the application state are stored as events. Lets take a simple blog system as an example. In this system we do not want multiple blog posts with the same title. Therefore — instead of adding an event for creating and an event for rejecting the post — we simple stop the processing and print an error message to the user.

One good reason for this whole stuff is scalability. In essence this means we need way more resources for your reading access as for your writing changes. This framework consists of two main parts, domain (writing access) and projections (reading access), which both get their own server to offer better performance. These servers run parallel along the main rails server and are independent from one another.

Lets take a look at a humble example and see how this everything works together:
We take the blog system again and we want to create a new blog post. After filling in the forms and pressing submit, the controller gets something to do, so far everything is just like in a standard rails environment. But instead of changing the model and then displaying the new contents, a command is generated with our data and our intention of creating a blog post. This command is then sent to the domain server, where the matching command processor gets executed. If we take a standard processor here, all it does is to validate the command and create an event with the data from the command. Our CreatePostCommand becomes a CreatedPostEvent.
So now we have that event and the command. First of all, the event gets stored in the database, then it gets published on an event exchange and last the domain own projection gets called with the data to ensure a persistent domain model. The projection server registered on his start to the event exchange. Because of that, he now gets the event, we just published and can process it. Lets say we have the simplest projection of all, the model itself without modifactions. So, we get that event and simply create a blog post in our model and save it. But maybe we have a projection, which holds the latest ten blog posts? Then we need to do more, because we also need to delete the oldest one, if we have more then ten, before we can store the new post.

And therein lies the beauty. Instead of creating and executing crazy SQL queries to get the latest ten posts, we only query our data table latest_post from the projection database and that’s it: We get the whole table and are done.

¹ Bliki: CQRS

² Event Sourcing