CQRS -A simple .NET application

Those days I’d like to learn about the CQRS. After some days of researching and studying, I got the CQRS journey from Microsoft. I’m very happy about it because it is really useful, it is really what I am looking for.

I learned and read several books regarding the DDD, CQRS and Event Sourcing in the past but I didn’t get it. My problem was that I didn’t have a real project to practice those ideas. So CQRS journey filled my gap.

In my opinion, to learn some codebase is to let make some changes to the code. In the CQRS journey, I’d like to change the code to use some other technologies, infrastructure. To simplify the learning process, I remove functionalities just retains some of them.

There are some benefits of CQRS application that we should know:

1. Scalability: Because the number of reads vastly exceeds the number of writes so by applying CQRS we can scale each side independently according to their need.
2. Reduce complexity: Normally, the write side includes the complex business logic but the read side is not. When mixing them into one model may lead to performance and transaction problems. CQRS helps us to optimize the write side by the normal form of the database and optimize the read side by denormalized the database independently.
3. Flexibility:
   • Freely make the change on the read side that doesn’t impact on the write side.
   • Simpler the write side than includes the read side
4.  Focus on the business
   •  When we choose CQRS approach, we tend to design our application based on the tasks that the application will do. As a result, we have to think more about the command and event in the system.
   •  By separating rea/write the solution more adaptable in the face of changing business requirements and technology trends.

I removed almost complex functionalities from the origin CQRS journey. I just keep the simple cases:

1. The write side
   • a. Create a conference that publishes the ConferenceCreated event if successful
   • b. Locate a conference by using an email and access code
   • c. Publish a conference that publishes the ConferencePublished event if successful
   • d. Unpublish a conference that publishes the ConferenceUnpublished event if successful
2. The read side
   • List all the published conferences
   • Display the conference details based on the conference code or slug
3. Command processor
   • Handle the ConferenceCreated event that generates the conference read model
   • Handle the ConferencePublished event that updates the conference read model status to publish
   • Handle the ConferenceUnpublished event that updates the conference read model status to unpublish.

The system overall

I introduce one more layer: Conference Admin Api and Registration Public Api so that we can support more client applications later on such as the mobile app, React app easily …

Besides the advantages of CQRS, there are some challenges we need to consider:

1. Eventually consistency between the read side and the write side. It needs some time to transfer the message from the write side to the read side. The messaging infrastructure is very fast nowadays.
2. Make sure that the message is delivered after write successfully at the write side.
3. Duplicate message: We need to design our message to be idempotent
4. Lost message: The messaging infrastructure can guarantee that messages are delivered at least once to their recipients.
5. Out-of-order message: The messaging infrastructure can handle this issue

The full source code here

Thank you for reading.