u/neoellefsen

Hey I want to explore a somewhat untraditional approach to CQRS to see to what extent it's viable.

Both CQRS with an outbox and CQRS + event sourcing enable you to validate business logic, in the command endpoint, against a synchronous model before you emit the event.

With "CQRS with an outbox" you validate business logic against the write side OLTP DB, and not the read model.

With "CQRS + event sourcing" you validate business logic against the current aggregate state reconstructed from the event stream, typically using snapshots, and again not the read model.

I'd like to know if it's viable to validate potential events against the asynchronous read model. It removes the need for a separate write-side model, reducing duplication and architectural complexity.

I'd like to know if it can be viable to a certain extent, I don't need my event logs to be as flawless as a well designed event sourced system. As long as state is reconstructed correctly then I don't really care about duplicate events in the log and stuff like that.

Have you guys ever considered NOT doing database writes in your customer facing http endpoints, where you instead chose to only emit an event (which you then caught in another endpoint in your app where you then finally did the db write)?

Normally you have an endpoint like POST /api/todo and in that endpoint you'd typically do something like INSERT todo into table. But what if you instead sent an event "todo.created", and then in another endpoint in your app POST /events/todo you inserted into the table.

Because then the db wouldn't be the source of truth anymore. In a regular event driven architecture the db is still the source of truth and events are emitted with an outbox.

With this Event-first pattern the db of your application is down stream just like the DB's of all your other services (that also are interested in the event).

If you persist the events and the order in which they came in then the obvious benefit becomes replayability, you can rebuild your db or bootstrap any new service with it's own interpretation of the event log data.

Is it possible to keep the db of the source application accurate if you keep it consistent by using events, without fully committing to event sourcing complexity?