Microsoft | patterns & practices | Developer Network | Enterprise Library | Acceptance Testing Guide | Personal Site
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:
After the first round of evaluation, we’ve ended up with 2 candidate domains:
Candidate #1 Events/Conferences management system with the following potential subsystems and properties: - programme/agenda management - session proposals/review management - attendees registration - event administration (incl. equipment, session attendance monitoring) - exhibitors and sponsorship management - reports, badges generation - session scores, attendees lists, event archives etc. - multi-tenant
Candidate #2 Public document review system for collaborative community feedback with the following potential subsystems and properties: - document lifecycle management - multiple tenants (host the collection of docs) - multiple authors (competing, collaborative app - true competition) - multiple reviewers (potentially performing tracked changes) - production/release managers
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:
Really like the #1. Think this domain is a domain which everybody can understand and have a clear mental model of it!
Like the 'RI Should' list, and agree on candidate 1.
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.
I would also opt for #1, since there is really a domain model to be discovered there IMO.
I assume there are a lot more edge cases to #1.
I also think that the conference lingo might make more sense to everyone, as opposed to the review lingo.
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.
Very fine choice! Really looking forward to it.
Fine choice. You might run into a little confusion about the term 'event', having it both in the domain and in the pattern-language (event sourcing), but you'll probably sort that out.
Use Case? I would like to see a query model being derived from an event source. For example: a bunch of events which influence the agenda, and then 'calculate' the agenda in the query model.
When do you plan on starting? Are you going to open source the sample?
@Livingston. Already started, we are in sprint 1. And yes, we'll be open-soucing the sample. See blogs.msdn.com/.../microsoft-s-cqrs-journey-project-to-take-community-contributions.aspx