The Reactive Monolith – How to Move from CRUD to Event Sourcing

Post by kortex » Thu, Sep 30, 2021, 11:48 AM UTC

_3u10 wrote: post #88

nivertech wrote: post #72

Earlier quoted context omitted.

Correct, and many applications are using WAL via CDC (Change Data Capture) to gain some of the benefits of the CQRS/ES. The problem is that the CRUD is only recording "What" change/mutation was done, but not "Why" by "Whom", and "When" it was done. With tailing WAL / CDC you can also capture the "When". This can be partially mitigated by adding audit fields like: Why (reason for change): created_bc ("because") / crea…

Yup a few fields gets you a long way, though I would recommend an audit log updated by triggers, rather than audit fields. For example on my CRUD rails app, we use audit triggers in combination with setting a postgres local config variable with the username, the audit triggers pull the user info from the variables and record them into the DB. With a little more work I could probably also pull a backtrace of what line…

Post by kephasp » Thu, Sep 30, 2021, 12:36 PM UTC

codeflo wrote: post #65

vegai_ wrote: post #56

Earlier quoted context omitted.

Two examples of systems that use a variant of event sourcing: - relational database systems (their journals and async replication in particular) - git Perhaps not so shit. Perhaps a bit practical. It's just a bad fit for some problems and architectologists like to say it's good for everything for obvious reasons. And it's should be pretty obvious that architecture doesn't matter at all if it's implemented poorly.

We have to be very precise here I think. Git doesn't really store file changes as events, rather, it's a long chain of state snapshots, in something like a persistent data structure. Sure, the history is all there, but so is the current state in its most efficient form. DB transaction logs might be considered event sourcing by some definition, but their use is very different. It's purely a technical trick. As a conse…

Post by bordercases » Thu, Sep 30, 2021, 1:01 PM UTC

blowski wrote: post #37

KingOfCoders wrote: post #23

As a proponent of Radical Simplicity, I'm always sceptical about event sourcing. There are some benefits (I found it useful to replay events for example), but where I have seen it at work it makes things much more complex, the understanding of the system and the development of new features takes much longer. This already starts with a command framework instead of method calls.

A competent dev experienced in event sourcing can build a system that leverages this without taking on so much cost. But… they’re expensive and hard to find. So most experiences of event sourcing look exactly like you describe.

Post by fullstackchris » Thu, Sep 30, 2021, 2:02 PM UTC

classabove wrote: post #47

blowski wrote: post #34

Earlier quoted context omitted.

I work on a bog standard ERP that was originally CRUD, but a whole module was refactored to event sourcing so clients could have a log and rollback. A couple of months back, a QA review reported a bug - the log system didn’t work. Turns out it’s never worked. Nobody has ever done a rollback either.

this is absolutely terrifying

Post by nivertech » Thu, Sep 30, 2021, 2:26 PM UTC

blowski wrote: post #96

kephasp wrote: post #92

Earlier quoted context omitted.

If the ES is "unnecessary", then it's not ES by definition. If events are not your source of truth, it's not event sourcing , just event logging.

I’m not sure what you mean. A car that sits in the driveway never being driven is still a car.