I am considering a CQRS refactoring process. It is more of a learning exercise in my spare time. The use case is similar to a price comparison website where a user enters their details for a mortgage and they are presented with mortgage options from service providers. For example, a user enters the minimum deposit; term; house value and then they are presented with options e.g. mortgage 1 from HSBC; mortgage 2 from NatWest etc. A user could make more than one request; adjusting the criteria each time. For example:

1) Criteria 1: 25 year term, £23,000 deposit, £150,000 value
2) Criteria 2: 30 years term, £20,000 deposit, £180,000 value

I believe I have two options:

1) Event Sourcing using event store.
2) Message Queue/service bus

With regards to option 1 - is this use case even suitable for event sourcing? The classic example of event sourcing is a bank account where you would be able to see what the balance was on date: x or date: y by replaying the events. However, in my case; the business would not want to know what the value of 'deposit' was on date: x. Each user search is new and independent of the last.

With regards to option 2 - I believe message queues (and service buses) are suitable when there is communication required with another microservice. In my case; the publisher and subscriber to the event would be the same microservice.

My analysis tells me that neither option is suitable because of the reasons stated in the two paragraphs above. Am I correct in this analysis?

  • Event sourcing is the option for keeping track of the history of the facts that happened in the past. So instead of a single snapshot of the current state of an aggregate root, you can generate totally new states later by replaying the facts. A message queue is a useful tool for sending messages between different applications (services). And you can use event souring if your requirements force you to have a history, otherwise, don't bother.
    – Mohsen
    Sep 12 '18 at 7:48

Accepting a request from the client and sending it to multiple vendors is a classic example of the Scatter-Gather pattern. It can be implemented using a message bus but not necessarily so.

Here it is described using the mortgage example.

enter image description here

Event sourcing should be used if you have at least a relatively complex process that can be modeled using events when you control the whole process. I don't see any business rules in getting the quote from multiple vendors to be honest.

  • I read your answer here: stackoverflow.com/questions/46154092/…. Could you point me to an article, which states the reasons for not using a message queue/bus with CQRS to synchronise the read model and write model? How would you deal with the scenario where the write model contains more/fewer records than the read model? Thanks again. +1 for the reference to Scatter-Gatherer.
    – w0051977
    Sep 10 '18 at 15:36
  • I think I mentioned it quite clearly. You can use a message bus if you can have transactions around both the write model update and publishing an event. For example, NServiceBus supports it using a persisted outbox. But not all CQRS scenarios can tolerate having a message bus. For example, replaying events for a particular read model if you using an event-sourced system would not be possible. Event sourcing is a subset of CQRS where a message bus will create trouble. Sep 10 '18 at 19:41
  • Thanks. In the answer you say: "when you control the whole process". I do have control of the whole process i.e. I have to write the code for Vendor A; Vendor B and Vendor C (see your diagram). On that basis I guess Event Sourcing could be suitable?
    – w0051977
    Sep 10 '18 at 19:53

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.