I am not quite sure I understood what an Eventstore is, I thought of it as some kind of "Transactionlog" for Domainobjects. What are the advantages/disadvantages of it and what are good scenarios to use it and when shouldn't it be used?
EDIT:
Since I may be asking too much, I would be happy if there would be a
"simple" scenario when to use an eventstore and when not? In other words: Is it possible to describe the 2 scenarios in just some sentences or do I need to read 5 Books to understand 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.