Microsoft   |   patterns & practices   |   Developer Network   |   Enterprise Library   |   Acceptance Testing Guide   |   Personal Site

Picking a domain for CQRS Journey RI - Grigori Melnik: Thoughts on Agile Software Engineering and Beyond - Site Home - MSDN Blogs

Picking a domain for CQRS Journey RI

Picking a domain for CQRS Journey RI

  • Comments 10

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.

Click to zoom

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:

  1. Be non-trivial (complex enough to create a real world model with real problems, but common enough for most people to understand)
  2. Be culture-independent (not dealing with taxes in US or financial rules of trading in Hong Kong)
  3. Be a collaborative app (in Udi Dahan’s sense) with potential conflicts
  4. Be end-to-end, including UI
  5. Be capable of being hosted on Windows Azure
  6. Consist of multiple bounded contexts involved (in Eric Evans’ sense)
  7. Require integration between various bounded contexts of different styles (CQRS, CQRS/ES, 2-layer CRUD)
  8. Have some high scalability requirements
  9. Deal with stale data (in some bounded contexts)
  10. Rely on temporal data, the time variable is important (in the context of sagas)
  11. Deal with out-of-order events (when handling events from different subscribers)
  12. Deal with event merging
  13. Be good to showcase sagas
  14. Be good to showcase versioning
  15. Be something we can implement within 2 months
  16. Be easily-deployable for people to play with it, with minimum pre-requisites, simulate whatever possible (2 hrs setup time max)
  17. Have a bounded context that is a smart/mobile client to demonstrate disconnected or occasionally-connected scenarios
  18. (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)
  19. Lend itself to work separation between multiple teams
  20. Be in a domain that we have access to a domain expert from, and who is passionate about the domain
  21. 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:

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:

  • 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?
Comments
  • Really like the #1. Think this domain is a domain which everybody can understand and have a clear mental model of it!

    Daniel

  • 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.

  • #1

  • 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

Page 1 of 1 (10 items)
Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post