CQRS implementation details

Question

I am implementing micro-services using CQRS and Event-Sourcing. I have seen different implementations of CQRS which are quite complex.

What I have understood and implemented is I have made two models for Read(Query) and Write(Command), the read model has a materialized view, and write model uses the Database, now whenever an update happens, the write model updates the database and generates an event, and logs the details to event store, which the read model has subscribed, and the read model updates its materialized view by reading from the event.

My question is whether this model is relying to the basis of CQRS and Event Sourcing?

Answer 1

the write model updates the database and generates an event, and logs the details to event store

That doesn't quite sound right. The write model doesn't update a database and an event store, it updates the database which is an event store.

The core idea of CQRS is that processing commands and processing queries can use different data models. If a bit of latency is acceptable, then we write the changes into one data model, then in the background we update the second data model to match the data in the first. Among other things, this allows us to choose data stores that are fit for purpose - if we need to support a bunch of graph queries, then we can use a graph database as part of the read model.

When we add event sourcing to the mix, the above pattern doesn't change. What does change is that the representation of state that we copy into the write store changes from a snapshot of current state to a snapshot of history. So our fit for purpose data store for the write model is an event store.

The event store replaces the snapshot database as the source of truth.

Answer 2

It sounds like you've implemented CQRS but not event sourcing. CQRS means segregating the write-side (commands) from the read side (queries), which it sounds like you're doing.

However, it sounds like your events are merely a way of communicating from the write side to the read side, while in even sourcing events are the source of truth. A write-side implemented using event sourcing would only persists the events (and optionally snapshots) but wouldn't do so after doing some other updates to the database. The data model on the write side would be composed solely of the journal of events (and optionally snapshots).