Foreword by Greg Young

I started off the new year on January 3rd with a few hour long meeting showing the team at patterns & practices a bit about Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES). Most of the team had previously not been exposed to these ideas. Today is almost exactly six months later and they have produced a document of over 200 pages of discussions and guidance as well as a full end to end example hosted in Microsoft Azure. This is certainly not a small feat.

When the announcement of the project came out, the twitter stream near instantly went negative as many thought that Microsoft was building a CQRS framework; which was premature from the community. The process followed similar paths to other patterns & practices projects with a large advisor board being set up. I believe however that the most interesting part of the process was the decision to host the work on GitHub and allow pull requests which is an extremely open and transparent way of communicating during the project.

One of the main benefits for the community as a whole of going through such a process is that people were forced to refine their vocabularies. There are in the DDD/CQRS/ES communities many different voices and often times, especially in younger groups, vocabularies will go down divergent paths leading to fractured community. An example of nebulous terminologies can be seen in the terms "saga," "process manager," and "workflow"; the community as a whole I believe benefited from the discussions over defining what it actually is. One of the most interesting conversations brought up for me personally was defining the difference between an Event Store and a Transaction Log as legitimate arguments can be made that either is a higher level abstraction of the other. This has led not only to many interesting discussions in the community but to a far stricter future definition of what an Event Store is.

"For the things we have to learn before we can do them, we learn by doing them. ~Aristotle"

The quote above was the team motto during the project. Many will be looking towards the guidance presented as being authoritative guidance of how things should be done. This is however not the optimal way to look at the guidance as presented (though it does contain many bits of good authoritative guidance). The main benefit of the guidance is the learning experience that it contains. It is important to remember that the team came into the ideas presented as non-experienced in CQRS and they learned in the process of doing. This gives a unique perspective throughout much of the text where things are learned along the way or are being seen through fresh eyes of someone recently having learned and attempted to apply the ideas. This perspective has also brought up many interesting conversations within the community. The patterns & practices team deserves credit for digging deep, facilitating these discussions, and bringing to light various incongruities, confusions and inconsistencies as they went along.

Keeping in mind the origination point of the team, the most valuable bits in the text that a reader should focus on aside from general explanations are places where tradeoffs are discussed. There is an unfortunate tendency to seek authoritative answers that "things should be done in this way" when they in fact do not exist. There are many ways to proverbially skin a cat and all have their pros and cons. The text is quite good at discussing alternative points of view that came up as possible answers, or that received heavy discussion within the advisor group, these can often be seen in the "developer 1/developer 2 discussions." One such discussion I mentioned previously in defining the difference between event sourcing and a transaction log. Many of these types of discussions come at the end of the guidance.

How might things be approached differently? One of my favourite discussions towards the end of the guidance dealing with performance is the independent realization that messaging is not equivalent to distribution. This is a very hard lesson for many people to understand and the way that it comes up rather organically and much like it would on most teams as a performance problem is a great explanation. I can say 100 times to apply the first law of distributed computing, don't distribute; however seeing it from the eyes of a team dealing with a performance problem who has already made the mistake of equating the two is a very understandable path and a great teaching tool. This section also contains a smörgåsbord of information and insights in terms of how to build performant applications in Azure.

Out in the wild, there are plenty of naïve samples of CQRS/ES implementations, which are great for describing the concepts. There are details and challenges that will not surface till you work on a complex, real-world production system. The value of the p&p's sample application is that it uses a fairly complex domain and the team went through multiple releases and focused on infrastructure hardening, performance optimizations, dealing with transient faults and versioning, etc.—many practical issues that you face when implementing CQRS and ES.

As with any project, people may disagree with implementation choices and decisions made. It is important to remember the scoping of the project. The guidance is not coming from an expert viewpoint throughout the process, but that of a group "learning by doing." The process was and remains open to contributions, and in fact this version has been reviewed, validated, and guided by experts in the community. In the spirit of OSS "send a pull request." This guide can serve as a valuable point to start discussions, clear up misconceptions, and refine how we explain things, as well as drive improvement both in the guidance itself and in getting consistent viewpoints throughout the community.

In conclusion I think patterns & practices has delivered to the community a valuable service in the presentation of this guidance. The view point the guidance is written from is both an uncommon and valuable one. It has also really been a good overall exercise for the community in terms of setting the bar for what is being discussed and refining of the vocabularies that people speak in. Combine this with the amount of previously difficult to find Azure guidance and the guidance becomes quite valuable to someone getting into the ideas.

Greg Young

Next Topic | Previous Topic | Home | Community