Picking a domain for CQRS Journey RI

About a week ago week we kicked off the public consultation process with a survey. We’ve received over 400 responses and a good number of people who volunteered for our advisory board. Thank you all very much!

While the survey is still open, we’ve started to analyze the responses. To help us with spiking, one of the first questions that we wanted to get an answer to was: "What domain should we pick for the reference implementation (in other words, the sample application)?" The challenge is to have something complex enough to create a real world model with real problems, but common enough for most people to understand. The survey respondents came up with many suggestions for the domain. Interestingly, while there were a considerable number of people who suggested financial applications, there were an equal number who explicitly asked us NOT to build a financial/banking app of any sort. Another significant proportion of the responses suggested the health care sector (hospital management app, patient management, pharmacy apps, health provider billing etc.). While this is interesting and surely complex enough, the big challenge for us here is the lack of domain expertise. Many other domains have been suggested from gambling to airport traffic control and everything in between. I’ve done a quick qualitative analysis with open coding and here’s the resulting word cloud (click to zoom) which provides an interesting perspective with the key codes surfacing up in the larger fonts.

There were also requests for a series of smaller RIs each focusing on a particular topic rather than a single RI. While this may be an interesting approach, we believe that one of the most significant values of applying CQRS is dealing with the domain complexity and therefore, we wanted the RI to be non-trivial. Besides, if you remember our intention of producing this guidance as a learning journey, there will be in fact several samples to learn from – essentially the progression through the system, introducing it with a fairly small and simple scenarios and adding complexity as we go along.

What the team did is we spent a few minutes brainstorming to define the desirable properties of the RI, which we later applied to the suggested candidate domains. Here’s our list of criteria.

The RI should:

Be non-trivial (complex enough to create a real world model with real problems, but common enough for most people to understand)

Be culture-independent (not dealing with taxes in US or financial rules of trading in Hong Kong)

After a round of quick consultation with some advisors, we are now leaning towards Candidate #1 – the Conference Management System. The domain is very clear and contains a lot of challenges that are prime candidates for CQRS/ES application. Besides, we have several domain experts on the team. As a former program chair of the Agile conference (with over 2000 attendees, 20 tracks and ~200 sessions), a track producer, and a regular program committee member, reviewer, submitter, presenter and attendee for quite a few other conferences, I’ve been in all the roles except that of the event planner. I feel confident we’ll get the domain right.

Let us know what you think:

Is this the appropriate domain for this project?

Do you have any suggestions on what particular use cases would be interesting to highlight and solve within the charter of this guidance, which is the CQRS/ES learning journey?

Do you foresee any specific challenges or stumbling blocks that we might encounter if we choose this domain?

I agree with the decision and like where this is going in terms of a non-trivial RI. Many of the things you find to demonstrate thes topics are trivial and am totally on-board with the approach here and look forward to seeing what comes out of this effort.

Thank you, everyone, for commenting on the domain. We are going ahead with the Conference Management System. I'd like to invite more comments on what use cases would be interesting to highlight from the CQRS/ES guidance perspective.