CRUD is good, except for maybe U and D, which are the proverbial erasers in "Accountants don't use erasers or they end up in jail".
It's all fun and games in the greenfield happy path. Do the wrong modification to someone's bank account? Just update the code so you no longer do the wrong modifications. Leave the bad data in-place. Or if you want to fix the bad data, maybe reach out to the customer to ask what his balance should be. Or check the dev-logs, you do make your dev-logs a better source-of-truth than the database, don't you? Once you 'know' what the balance should be, just use your CRUD operation to set things right, aka "create money".
I agree with the article that exposing R and U interfaces on all entities is a completely natural, human way of think about it. It allows for completely intuitive patterns like "check-then-act" and "read-modify-write", (which are also the names of race conditions.)
EDIT:
I forgot to comment on the obvious fallback here. If you really screw things up, it might be possible to restore your database to an earlier state, and just disappear all the money which moved through the system after the database snapshot was created.
> CRUD is good, except for maybe U and D, which are the proverbial erasers in "Accountants don't use erasers or they end up in jail".
And people storing other people's personal data end up with fines if they don't remove the data on request. The whole situation got so bad, that timescale had several bugs which prevented U and D of single records, you could only delete a shard. At least C and R is fast.
It's all fun and games in the greenfield happy path. Do the wrong modification to someone's bank account? Just update the code so you no longer do the wrong modifications. Leave the bad data in-place. Or if you want to fix the bad data, maybe reach out to the customer to ask what his balance should be. Or check the dev-logs, you do make your dev-logs a better source-of-truth than the database, don't you? Once you 'know' what the balance should be, just use your CRUD operation to set things right, aka "create money".
I agree with the article that exposing R and U interfaces on all entities is a completely natural, human way of think about it. It allows for completely intuitive patterns like "check-then-act" and "read-modify-write", (which are also the names of race conditions.)
EDIT: I forgot to comment on the obvious fallback here. If you really screw things up, it might be possible to restore your database to an earlier state, and just disappear all the money which moved through the system after the database snapshot was created.