Software Design Blog

Journey of Rinat Abdullin

Let's Scale Out CQRS Sample Project

Yesterday I’ve written a blog post on Focus for next iterations in Lokad.CQRS Sample Project in order to try to prioritize things that could be done to improve this open source project of ours.

Then, Kerry Street took the effort and time to write down a vision of prioritized backlog for Lokad.CQRS along with really encouraging feedback. The problem with that was that I want to do all of that but don’t have enough time!

Sharing with community is both fun and rewarding experience. And we are doing really cool things all the time (these are needed to move forward). For instance, a month ago we discovered Bootstrap v1. Today we’ve pushed into production an internal project that features some slick Bootstrap v2 UI on top of Lokad.CQRS with user experience being ripped off from Twitter and Github.

But there is a bottleneck in Lokad - we have too few people and not enough time to share properly all that we discover and learn from others. It can either be series of crazy blog posts that make sense only to people from CQRS Beers OR properly written series of articles that nobody has time to keep updated with the latest simplifications.

Let’s Refactor

Then it hit me - what do we do with bottlenecks in software? We identify boundaries, break into smaller pieces, partition and then kick some major ass. We scale out.

Let’s think about scaling the actual Lokad.CQRS open source project out!

There are currently 2 elements:

  • Lokad Teams that have pleasure of working in challenging conditions, while pushing the edge and having the pleasure of learning from best minds and great friends. Aside from having practical experience with Lokad.CQRS in varios scenarios and clouds, we also do research, aggregate public and private feedback, while incorporating it into the same vision.
  • Community that is eager to learn things that could help to apply technology to solve important things and achieve amazing results.

Lokad is the “server” and “aggregate root”. This allows us to be internally consistent and non-contradicting over the language, concepts and vision. Community is the greatest client. What do you do, when server can’t handle the load of doing some writes AND serving numerous read requests to the client? Right, let’s split the entire thing to unload the server.

Let’s say that Lokad gives up on challenge of keeping updated all the numerous CQRS resources (my bliki series, CQRS starting point, CQRS wiki that didn’t get past the point of registering the domain, CQRS dive, screencast idea etc) and instead focuses on providing consistent story that starts from the very beginning and covers various CQRS aspects with a single vision (practical and simple stuff).

The story (delivered via RSS) will be consistent in vision, language, while sharing the latest lessons. It will deliver knowledge in various forms: articles, snippets, updates to major Lokad.CQRS Sample Project, videos, podcast recordings, screencasts, interviews, virtual CQRS Beers etc - everything that provides the most efficient way to share knowledge the community without spending too much time on small things.

In other words - we can stream and share knowledge and experience much faster than we can properly document and publish it.

Obviously going through the entire stream is not a good fit for everybody, especially students of the art, who want to get a glimpse of the subject.

Now, this is where you, my Dear Reader, can come into play and help us and the community.

Call For Help

Would you be willing to stay tuned to that RSS stream (I’ll be “replaying things” starting from the very basics) and also taken on the responsibility of keeping on updating some small piece of public guidance to the latest version (according to your understanding of the latest news)? This piece (or persistent read model, in other words) could be something as simple as:

  • keeping an updated list of videos or recommended books;
  • maintaining list of Frequently Asked Questions;
  • updating a some small specific sample to the latest “best practices”;
  • Keeping an eye on Wiki page on some CQRS topic;
  • maintaining a small focused sample in a platform of your choice;
  • translating a single wiki page into your language;
  • etc

If you get any questions or problems while doing that, we will gladly provide answers and guidance. These will also be shared over the same event stream, potentially causing updates and improvements in the other “projections”.

If we can’t answer the question - we have some amazing friends around the world with great insight and practical experience, that we can ask for help (don’t tell them that I called then “unique domain services”)

I know that:

  • it is crazy to apply principles of event-centric architecture to an open source project;
  • nobody has really done this before;
  • this will be an excuse for more CQRS Beers down the road;
  • this entire thing can fail :)

But I believe that together we can really scale this thing out between multiple people and do some good to dev community at multiple levels: from beginners to the specialized experts. While doing that we will learn together and will push the state of the art.

So what do you say?

If you are interested in giving a try to this approach and willing to help out, then I’ll setup the infrastructure, provide some initial suggestions and start that event stream. No wasting time, and we’ll figure the details out later.

Are you interested? :)