I first heard about CQRS/ES in a ScalaDays San Francisco presentation some months ago. Since then, I have noticed occasional mentions of the terms in technical writing, most recently Fiverr's blog post on the topic.

It's seemed very interesting so far, but I have encountered a number of related issues, and I am wondering if there are any common solutions:

  • How do you deal with eventual consistency and potentially inconsistent views in the short term?
  • How do you deal with business logic which touches multiple resources a.k.a. atomic reads/writes a.k.a. transactions?
  • How do you deal with use cases where the user interface requires an immediate result to the request?

Moreover, what are some advantages of adopting this pattern, and how do they exceed the cost of the extra layer of complexity?

Thanks in advance!

2

There are 2 answers

0
Phil Sandler On BEST ANSWER
  • How do you deal with eventual consistency and potentially inconsistent views in the short term?

  • How do you deal with use cases where the user interface requires an immediate result to the request?

It is a common misconception that using Event Sourcing automatically implies an eventually consistent read model. Many ES practitioners (up to and including Udi Dahan and Greg Young) recommend starting with a synchronous, immediately consistent model and moving toward eventual consistency only when it is needed.

  • How do you deal with business logic which touches multiple resources a.k.a. atomic reads/writes a.k.a. transactions?

This is a complex question that doesn't have a single answer, and may be more appropriate for a discussion forum vs a Q/A forum like SO. I would recommend poking around (and posting) in the DDD/CQRS discussion group.

0
Ming On

Additionally, here are some slides I recently found on the topic. They cover a lot more of the "why"/"why not" aspects from a team which used CQRS/ES in practice.

http://ookami86.github.io/event-sourcing-in-practice/