31

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?

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
Bernhard Kircher
  • 4,132
  • 3
  • 32
  • 38

2 Answers2

53

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.
Eric Lee
  • 8,181
  • 4
  • 21
  • 18
20

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.

jub0bs
  • 60,866
  • 25
  • 183
  • 186
Craig Wilson
  • 12,174
  • 3
  • 41
  • 45
  • Thanks for your answer, the links helped (although I think I already knew the most of them). Just saw your update in the answer- that helped more. Upvoted your answer but I think Eric Lee's answer fits my question better. – Bernhard Kircher Feb 10 '12 at 10:02