1

I understand that basic stats in the read model can be computed on the fly as events from the domain model are generated. Does this really work for more complicated situations? What happens if new stats are required in the future - do you run past events against the new read model retrospectively? Any feedback related to reporting and cqrs would be very much appreciated.

cs0815
  • 16,751
  • 45
  • 136
  • 299
  • 1
    I'm currently working on a solution where we take all events daily, and generate invoices based of that - would work the same way for reports. We do a projection of 1.000.000 events in 30 seconds. – JefClaes Jun 02 '14 at 10:23
  • Thanks sounds cool - just a quick one - let us say the reporting ui also has some filters on it. how does the 'projection' look like? I guess it would be very hard to create all possible events for all possible filter combination to 'project things'?! – cs0815 Jun 02 '14 at 13:21
  • You do the projection in the background to a read model that's suitable for reporting - a relational database for example. You would still implement filters by writing queries. – JefClaes Jun 03 '14 at 10:20
  • I think I get it all but I would really love to see a serious example on this. Not like this very basic example: https://github.com/stlaltdotnet/20110824-cqrs-event-sourcing/blob/master/GrokMob/GrokMob.ReadModel/Denormalizers/StatDenormalizer.cs - any pointers would be very much appreciated. – cs0815 Jun 03 '14 at 10:42
  • https://github.com/yreynhout/Projac – JefClaes Jun 03 '14 at 13:25
  • @JefClaes - I might not get it but how does Projac, which mainly helps me with 'non-query statements', help me with reporting needs (it focuses on the insert/delete/update rather than the select against the read model - if we assume that the read model is stored in a sql db). What I am interested in is how to structure the read model for powerful reporting purposes. – cs0815 Jun 03 '14 at 15:54
  • You might be better off reading into building good schemas for OLAP. – JefClaes Jun 05 '14 at 11:21

1 Answers1

3

I suppose you're talking about event sourcing, as CQRS does not necessarily mean you're storing events.

In the case of event sourcing, yes, you can just drop your entire read model and rehydrate it from past events. The idea in event sourcing is that your event stream is the log of everything what happened.

The read model is just a projection of those events. It's possible to change that projection when your insights change (or add projections for that matter). That's one of the great strengths of event sourcing.

Kenneth
  • 28,294
  • 6
  • 61
  • 84
  • I refer to this example: https://github.com/stlaltdotnet/20110824-cqrs-event-sourcing especially this code: https://github.com/stlaltdotnet/20110824-cqrs-event-sourcing/blob/master/GrokMob/GrokMob.ReadModel/Denormalizers/StatDenormalizer.cs Here the domain model generates events which are used to create the (reporting) read model. I guess this requires explicit event sourcing but I am not 100% sure ... – cs0815 Jun 02 '14 at 07:55