I'm building an application which lets users view a large amount of data about a single single entity (lets say it displays a users health profile for the day) via a single webpage. The data comes from an external API in a single JSON response, which is requested when a user views a profile page.

I have no control over the data coming in, but I would like to store this unnormalised data in my own database each time a user page is viewed. The idea is to build a history of each profile, so I can display a 'progress over time' of a users health profile.

I also want to report, gather statistics, and display leaderboards from the data, i.e. "User who has ran the most kms this week", or "User with the fastest 200m freestyle this month".

I have read about CQRS but never used it. I remember reading that it's useful for situations where you are storing large chunks of unnormalised data from a single source into a database, which seems very similar to my situation.

It would be great to hear from someone with experience using CQRS. Does this seem like a valid use case? Or am I adding unneeded complexity to my system?

  • Read this article by Martin Fowler. Note that your assertion about "storing large chunks of unnormalized data" is never mentioned. There is a "When to Use It" section at the bottom of the article. – Robert Harvey Oct 28 '19 at 4:13

As you know CQRS stands for command query separation. To rephrase it we divide the application in to two parts one responsible for read and another responsible for write. There are advantages and disadvantages when we split the application in to two parts. Let's look at the advantages/disadvantages and then may be you can decide if CQRS is worth it for your case

  1. The read model (applications) could are a good fit for reports. The reports in any system will change quite frequently to meet the demands of the users. The reports are not really that close to the domain. So splitting the application in two parts gives you benefits of keeping the write model slim and loaded with domain logic and read model will have all the reporting logic.

  2. Following CQRS, lets your read and write applications scale out independently. For most of the system, the read part will be used frequently and needs to scale out faster

  3. Following CRQS will help in maintaining the complexity of write model low.

  4. The same business objects will be needed with all its properties and reduced number of properties for reporting in different scenarios. So naming this business objects will be difficult. When we implement CQRS, then the objects could be named for comfortably based on the scenario where it is used

  5. When we decide to follow event sourcing. The entities will not be persisted. There will be a set of events that are persisted. The entities will have to constructed by replaying the events that are associated with it. In this case it would not be possible to query for entities based on its properties. At this case CQRS becomes very useful.

These are the few cases where I find CQRS advantageous. In most other cases CQRS brings in a complexity that is unwarranted. Read Martin Fowler's article to get more insights here: https://martinfowler.com/bliki/CQRS.html

In your case the write model is not having much of complexity. It's just persisting data that you are getting from another API. So most of your complexity is only on the read model side. So splitting the application here seems like overkill to me. I would prefer to do it without CQRS.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.