Comments on: How we got rid of the database–part 4

By: Anonymous

Anonymous — Thu, 21 Jun 2012 13:12:00 +0000

Normally you do not have different read models that need to be synchronized. Each read model, or may I rather say each projection or view model is constantly/continuously updated by the events that are (asynchronously) published by the domain (aggregates). There is no (and never should be) inter-dependency between different read models/projections.
And yes, in general the read model is only a tiny bit stale (in the range milliseconds to seconds).
Validating the credit card usually is be part of the (synchronous) transaction but this is not a requirement as long as you foresee compensating actions in case of failure…

By: Wayne M

Wayne M — Thu, 21 Jun 2012 11:30:00 +0000

So basically you do small enough commands that you can assume it succeeds and act as though it does, but maybe send a notice later to the customer (let’s go with an e-com example as that’s what I’m familiar with) if there was a problem? Let’s use a real-world example. My company lets people book freight shipments online and choose what carrier they want to pick it up, and pay for it all online – the quote then goes to our backoffice system where an agent follows up with the carrier to make sure the shipment is handled and keeps in contact with the customer. The idea here would be to handle each of those things (e.g. getting the quote, paying for the quote, etc.) as events, without worrying if the customer’s credit card couldn’t be charged (bad example though as we kind of have to wait for that) or if the carrier they chose is available? So if they choose ABC Freight and later on something happens whereby ABC Freight can’t service the request (this part is handled in the backoffice system), the agent would initiate that event and either that or more likely the agent would notify the customer to let them know?

So is the idea to have one read model for the different applications, or would the frontend have a different read model than the backoffice system? I guess that part comes down to specifics; it might be okay to replicate data or it might be okay to use the same depending on the actual data needed?Also, I’d like to know how you deal with synchronizing the data. It seems the overall idea here is to only use a true database for the commands, and use a file or object DB or something that isn’t an RDBMS for the read-model, but that data has to be synced at constant intervals so the read model data is only a little bit stale. I suppose that would be a good use case for SSIS or to a lesser extent some kind of batch script that runs to take data from the RDMBS and update the read model?

By: The Morning Brew - Chris Alcock » The Morning Brew #1129

The Morning Brew - Chris Alcock » The Morning Brew #1129 — Thu, 21 Jun 2012 08:34:12 +0000

[...] How we got rid of the database – part 4 – Gabriel Schenker continues his discussion of how he does CQRS and event souring looking in this part at the concepts of eventual consistency, discussing its important role in how a CQRS / Event sourcing way of working. [...]

By: Chris Martin

Chris Martin — Thu, 21 Jun 2012 04:57:00 +0000

I can echo everything you’ve said in this post.

I’ts refreshing to see this model of application being used by more people. We’ve built our application on top of Lokad.Cqrs going on two years now. It’s very stable and with some creativity, very powerful.