News for hackers. Stuff that matters.

A comment on Mistakes we made adopting event sourcing and how we recovered. Parent comment

Re:Mistakes we made adopting event sourcing and how we recov... by edvinbesic on Monday July 01, 2019 @10:10PM (#20331538)
One thing you do get "for free" pretty much is an audit log though. Each event can easily have an ID associated with it in case you need to be able to trace such a thing. Of course you can model this outside of a CQRS system but then you basically have created a CQRS system.
[ Parent | on HN ]
Re:Mistakes we made adopting event sourcing and how we recov... by stevesimmons on Tuesday July 02, 2019 @01:24AM (#20332370)
And if you store events with both an event_timestamp and effective_timestamp, you get bi-temporal state for free too.

Invaluable when handing a time series of financial events subject to adjustments and corrections. For instance, backdate interest adjustments due to misbooked payments, recalculate a derivatives trade if reported market data was initially incorrect, calculate adjustments to your business end of month P&L after correcting errors from two months ago.

[ Parent | on HN ]
Re:Mistakes we made adopting event sourcing and how we recov... by nullwasamistake on Wednesday July 03, 2019 @02:20AM (#20342065)
You get audit logs for free on a regular database with an ORM like Hibernate or even support on database snapshot level with Postgres or MSSQL. You get the logging capabilities of CQRS without any of the complexity.

After working on several such systems, I strongly believe you should keep data storage concerns in the database. Moving it to code implementation is a massive amount of overhead for no benefit.

[ Parent | on HN ]