In a CQRS architecture with no explicit read model, which handler updates the data store?
architecture, cqrs, design-patterns
Solution
I think you may have better luck with a question like this on a CQRS forum, since this may require more of a back-and-forth discussion. Plus the real answer is probably "it depends".
That said, it sounds like you are mixing the "strict" definition of CQRS with more of the "accepted" definition of the pattern. The former is merely a separation of the read logic and write logic (and their structures). The latter is usually defined as having a highly denormalized read model and usually involves some form of event driven architecture (including event sourcing is some cases).
It sounds like you have something of a mix of these two ideas. My first question would be: what are your event handlers doing if they're not creating denormalized read models? Are they just notifying subscribers to invalidate cache and refetch data?
But bottom line, I think your instinct is correct--the event is published after the data has successfully been updated. If one handler's responsibility is to update the (command/write side) database, other subscribers have already been notified that this happened which may not be true if the update to the database fails.
So your command side should update the database, and your reads should be querying your normalized data store and projecting the results onto denormalized result sets. Again, events (if used at all) would probably just be used for notification that data has been updated, and that subscribers may need to requery (again, like cache invalidation).
Problem
This question has arisen out of a kind of existential crisis in an evolving architecture. Essentially it comes down to asking this - when the read model is the command model, should the command handler or the event handler update the data store? Particularly I'm curious to know if there's an accepted way to approach this and if going down one route or the other could lead to well known problems. To elaborate, we started with a domain model and some repositories to read from and update the data store via an ORM. These repositories query the existing domain model and we map results to DTOs - we didn't think about creating a separate read model at this point. The architecture has evolved to use the CQRS approach, so we're now issuing commands to create domain objects and events are being raised when commands are handled. At this point we now have some fairly complicated model objects with all kinds of calculations going on and have (finally) realised that reads would be a lot faster if we persisted these calculations. So far so unexpected. There is an idea to persist these calculations by adding fields to the current data store tables, thereby making our command model more like a read model. It has therefore been argued that we should be updating the data store in the event handlers because that's where the pattern says the read model should be modified. i.e. if we issue a `CreateItemCommand` which is handled by a `CreateItemCommandHandler` which raises an `ItemCreatedEvent`, in turn handled by some `ItemCreatedEventHandler`, then the `CreateItemCommandHandler` should be reduced to merely validating the command and the actual modification of the data store should happen in the `ItemCreatedEventHandler` The logic seems reasonable but it also seems to create a counterintuitive architecture. I thought the CQRS pattern required that a success event from a command handler indicate that something actually has changed in the domain model? I can understand not wanting to update the read model in the command handler but not doing anything at all seems wrong, especially since we won't then be able to trust the `ItemCreatedEvent` to be telling the truth. Is this ultimately subjective, or could there be other concrete reasons to go one way or the other?