As others have said on this page, event sourcing is one of those technologies where if you don't know what it is, you certainly don't need it. Even if you do kn

As others have said on this page, event sourcing is one of those technologies where if you don't know what it is, you certainly don't need it. Even if you do know what is, you usually don't need or want it unless you have no choice. In event sourcing, instead of having stateful objects, you have a log of events that you use to build that state. It gives you powerful rollback, backup, and history features at the expense of some insane code complexity (usually solved by tooling). When paired with CQRS, another architecture separating reads and writes in your abstractions, and done well with events that are domain oriented ("AccountingReconciliationStarted" instead of "StartButtonClicked"), you can hide most of the code complexity and allow developers and less technical users to focus on domain complexity (i.e., the logic that matters to the real world). At least in theory.