Design Discussion

Imported from Google Groups
1

Axon users and CQRSers…

Have been working with CQRS for a while now and am seeing a traditional CQRS antipattern emerging as a controversial aggregate oriented pattern.

Traditional CQRS is where you update into aggregate, send events to reporting store and read from reporting store. This is great for data which is in reporting streamlined format/view data.

A lot of times data needs to be read in an aggregate orientation for the application. That is where we are seeing that the Aggregate and its entities stored in aggregate are easily accesible for reading. Now, the problem is that if you don’t do that you land up duplicating aggregate oriented storage on the reporting side for that type of data access with a lot of duplicate code and similar data.

Fowler has written about this term aggregate oriented data storage and access in the noSql book, which I think is interesting vs traditional never read an aggregate store policy.

This is more of a dilema and want to get opinion from the crew here on their thoughts as there are pros and cons to both approaches with respect to reading and writing from aggregate store.

One problem we have run into is that we land up storing object blobs similar to aggregate in the reporting store after trapping events and reading the object oriented aggregate oriented storage from reporting store, which seems redundant once you see the pattern repeating and related code bloat for handling events and storing data in the reporting store in an aggregate oriented format for domains.

Wanted to get a discussion going on other peoples experiences on design and thoughts and opinions.

Thanks and Cheers…

2

Hi,

interesting point. But first of all, I’d like to stress that it is not always bad to read from the ‘write’ side. Things really depend on how complex the models are, how consistent the data must be and how many times the data is updated.

The scenario you express looks very much like a crud scenario. In the write model, you should focus on behavior. If there is no behavior (other than setting data), you should really question the need for a command model in that area,let alone event sourcing.

I have been involved in quite a number of CQRS projects. Axon is not a fit for all of them. In some cases, especially when the behavior is data-oriented and there only read-model (thus no need for events), I tend to implement it without Axon.

Axon works best for projects with a complex write model and multiple read models. They require a separate (maybe event sourced) command model and events to update the projections. When applications are simpler, Axon can still be a good fit, but there is a point where the traditional approach is just better.

Cheers,

Allard