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)
- Be a collaborative app (in Udi Dahan’s sense) with potential conflicts
- Be end-to-end, including UI
- Be capable of being hosted on Windows Azure
- Consist of multiple bounded contexts involved (in Eric Evans’ sense)
- Require integration between various bounded contexts of different styles (CQRS, CQRS/ES, 2-layer CRUD)
- Have some high scalability requirements
- Deal with stale data (in some bounded contexts)
- Rely on temporal data, the time variable is important (in the context of sagas)
- Deal with out-of-order events (when handling events from different subscribers)
- Deal with event merging
- Be good to showcase sagas
- Be good to showcase versioning
- Be something we can implement within 2 months
- Be easily-deployable for people to play with it, with minimum pre-requisites, simulate whatever possible (2 hrs setup time max)
- Have a bounded context that is a smart/mobile client to demonstrate disconnected or occasionally-connected scenarios
- (Optional) Be something useful to us once we build it(that way we can keep it real, do versioning and it will help us in the future revs of the guidance itself)
- Lend itself to work separation between multiple teams
- Be in a domain that we have access to a domain expert from, and who is passionate about the domain
- Be a good fit for using event sourcing and explaining event sourcing
After the first round of evaluation, we’ve ended up with 2 candidate domains:
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.
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:
- 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?