Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When to use an Eventstore

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?

like image 978
Bernhard Kircher Avatar asked Feb 07 '12 13:02

Bernhard Kircher


People also ask

When should you use event sourcing?

Indeed, Event Sourcing shines the most when we can work with the business to find the business events. Event Storming and Event Modeling proved that events work great as a way to describe business processes. We can use them as “checkpoints” of our workflow. Events are also essential as a data model.

Why do we need event store?

Applications persist events in an event store, which is a database of events. The store has an API for adding and retrieving an entity's events. The event store also behaves like a message broker. It provides an API that enables services to subscribe to events.

What database is used for event sourcing?

On the technical level, event sourcing can be implemented using dedicated storage systems, as well as general-purpose "NoSQL" and SQL databases. If you're interested in the origins of event sourcing, the articles by Greg Young on event sourcing and CQRS are a great place to start.


2 Answers

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.
like image 156
Eric Lee Avatar answered Oct 06 '22 05:10

Eric Lee


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.

like image 29
Craig Wilson Avatar answered Oct 06 '22 06:10

Craig Wilson