This comment just made it finally click for me why event sourcing sounds so good on paper but rarely seems to work out for real-world projects: it expects a level of correct-design-up-front which isn't realistic for most teams.
> it expects a level of correct-design-up-front which isn't realistic for most teams.
The opposite is true.
A non-ES system is an ES system where you are so sure about being correct-up-front that you perform your reduce/fold step when any new input arrives, and throw away the input.
It's like not keeping your receipts around for tax time (because they might get crinkled or hard to read, or someone might want to change them).
> it expects a level of correct-design-up-front which isn't realistic for most teams
It requires a business that is willing to pay the maintenance cost of event sourcing in order to get capabilities needed capabilities (like an audit trail or replayability).
I already refrained from introducing event sourcing to tackle wierd dependecies multiple time just by justaposing the amount of discipline that the team has that lead to the current state vs the discipline that is required to keep the event source solution going.
