Thread by @Aaronontheweb

Some developers objected to my insistence on using event sourcing by default, claiming that auditing features of modern databases are sufficient.

My mistake: the biggest benefit of event sourcing is not auditability, it's optionality.

https://twitter.com/Aaronontheweb/status/1405834894102695937

If I have the history of state changes for my business entities preserved it creates options for the following:

1. Replaying old data with new code (simulation)
2. Creating novel features and experiences from old data (projections)
3. Reverting objects back to previous states

4. Introducing new ways of modifying business entities that can easily be reconciled along with prior ones

These are all extremely valuable and powerful future-facing tools that you will regret not having once you, inevitably, encounter a customer request that necessitates them

Data is cheap to store but intrinsically valuable to any business. Destroying the value of the latter in order to reduce the cost of the former by default is utterly moronic.

So my new rule: event-sourcing always, by default. Better to pay for the upfront developer cost of added complexity (minor, IMHO) than to have the history of your entire business be lost.

In order to build software without it, you have to prove that you don't need it

There are definitely cases where you don't, but weaponizing the precautionary principal and forcing to start from a safer, optionality-preserving default will result in much better software being built. Not different from arguing that deployments must be done from source control