CQRS, still doesn't get it completly, what is saved in the DB ;( [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Closed 8 years ago.

• Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
• Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.

Improve this question

I watched and read a few tutorials about CQRS, but ALL of them don't use a real world example, all of them (To makes things easy) had only an in memory event store. And in this example, it is easy and fast to get the current state of an object from "replaying" the events.

But how does this work in an real word example with sql database. Let's say I have a system with users.

And I have UI where I can Add and Edit users, BUT also get a list of all users.

Now, based on what the tutorials say, I have my events saved in the db, let's say each user have 3 changes on their profile and we have 100.000 users.

Now I have a repo with GetById. In a normal non CQRS system, I get exactly one record based on the Id. Fast and small resource usage.

But now on a CQRS system, I have to load 3 records from the DB and apply them on a new user object and return this...that's not that performant, but would be a thing where I can say: "Maybe life with it, because of the logging benefits and so on".

But how do I the list user scenario where I show 50 users on one page. 50 times x 3 records and this for each page click??? And this not only for customers, maybe invoices, bookings and so on, what resource waste is this?

Do I get something completly wrong about CQRS/EventSourcing or do I have life with this drawbag?

Kind regards

Answer 1

Denormalized read model/persisted view model is what you are missing. The main benefit of CQRS is being able to treat reads and writes differently and optimizing them differently. You would load aggregates with events for writes. For reads your system would just read a table created for the purpose. That table maybe SQL or NoSql and probably doesn't involve joins etc.

See Microsoft patterns and practice CQRS journey for example http://msdn.microsoft.com/en-us/library/jj554200.aspx

Answer 2

I think (and I'm a novice at CQRS I should point out) the key to thinking about this is to split the concepts of reading data and writing data. In your case you would need to create a store of data that could be read for your listing pages. This store would be read-only and updated when a write occurs into the event store, or even recreated by replaying all the events (e.g. if it was corrupted).

Answer 3

Yeap, you're wrong. You cannot use the write side for querying. You must create a denormalized storage using listeners that react to domain events (could be asynchronously). Then use this storage for fast queries.