10 problems that Event Sourcing can help you solve

I recently ended up in a discussion on when Event Sourcing is the right architecture style or not. As the universal answer to this question tends to be “it depends”, I started thinking about the typical problems where I would use Event Sourcing. I came up with a couple of them, some more functional and some more technical. Here’s a summary of those thoughts.

1. Auditing; Since the truth behind the domain in Event Sourcing are the domain events, they form a natural and unambiguous log of what happened exactly in time. Although this is often used as one of the USPs of Event Sourcing, I don’t think it is a very strong one. Most databases already provide some kind of change log out of the box, even though they are often much more technical compared to the business intent typically captured by domain events.
2. Replaying production issues; Imagine your domain has complicated or dynamically toggleable business rules and you want to be able to replay the exact steps that happened during that production issue. This is where Event Sourcing shines. You just replay the events one by one and see how that affects the state of the domain every step of the way. And this is not just a theoretical idea. We really solved several production issues that we would have never solved without Event Sourcing.
3. Collaborative domains; A lot of software systems have a domain where it’s not very common that multiple users act on the same domain objects at the exact same time. Using optimistic concurrency where…