When to use an Eventstore
That's a lot to ask for in a stackoverflow question. One thing missing from your question is what its disadvantages are? Anyways, rather than answer here, I'd like to provide some links to videos for you to watch. There is a lot of context that needs to be set before the answers to this question make sense.
Greg Young: There is a ~2 hour video here that provides a great overview of everything you are asking for in your question. There is also a ~6 hour online class here.
Udi Dahan: There is a 1 hour video here that gives perspective on when to use these technologies.
Mailing List: There is a group here where you can ask all your questions and have a nice discussion around the topic.
Hope this is helpful. There is just so much loaded into your question that I don't think it would possibly do you or anyone else any good to try and answer it in a short diatribe and mislead people.
Update: I don't think you need to read 5 books or even view the videos below. I think it is well worth your time to do so, but not required. The problem with your question is that "simple" scenarios generally don't need event sourcing. Most applications will be mostly CRUD and data-driven. Perhaps this is an answer to your question. If there isn't much "behavior" in your system, then you don't need it. If there is lots of behavior, then you might need it.
Yes, event sourcing is like a transaction log for your domain objects and the transaction log is the authoritative source of all of your data. You might have copies of the data in other forms designed for easy querying but they're merely copies that can be deleted and rebuilt at any time. The transaction log is the one source of truth.
I agree with Craig that it's hard to answer your question succinctly because it's very context-dependent, but here is a short list of reasons why you might consider using an event store:
- You care about doing complex historical analysis of your data. For example, someone might come to you in the future and ask, "How many of our customers put an item into their shopping cart, then took it out, but after we sent them a coupon, came back and bought it?" There can be an endless supply of such BI questions and you can't anticipate all of them ahead of time. If you capture all of the events in the system you can reconstruct the answer to any future question.
- Similarly, you care about auditing and being able to prove without doubt exactly who changed which data at what time and why. Your event store is your audit log.
- You care about having a highly-scalable system. Since the write model of an event store is append-only, it can be well-suited for high-volume applications. Because it's not inherently relational, it can usually be partitioned easily.
On the other hand, there are some good reasons not to do it:
- You don't have any of the needs listed above.
- You don't want to deal with the hassle of having to build debugging tools to be able to easily view and modify data in the event store.
- You're building a short-lived project that you don't expect to be around for a long time so you don't want to invest a ton of architecture effort into it.
- You're not prepared to learn CQRS, DDD, and EDA at the same time as event sourcing. Those ideas aren't strictly required for event sourcing, but they're often intertwined and the true value is found when you completely change your paradigm and use them all together. Event sourcing is part of a package of techniques that together represent a very different way of thinking about software architecture. It can be intimidating.