Event-Sourcing definition

Question

Is "Event-Sourcing" a fancy name for a application that implements "Command Handler Pattern" that saves each command successfully executed (SeatReserved, OrderCanceled, BlaBlaBlaDone), only does inserts (no updates and no deletes, e.g: Balance +100, Account Closed) on the database and all selects are similar to select top 1 MailAddress from UserAddressTable where UserID=@value order by lastUpdated desc or select sum(balance) from UserTransactions where UserId=@value???

Answer 1

Your proposed definition of the Command-side is basically spot on.

However, no-one says that you'd have to store the events in a relational database. In fact, that's often a poor choice. When working with a simple bank account example, you may know in advance that you're going to need a balance, which means that you may maintain the up-to-date balance in a database table.

However, in systems removed from a normal bank account example, you may not realise in advance exactly how all the events are going to be interpreted.

That's why Event Sourcing is valuable. You never throw away data, so if, in the future, you realise that you'd like to perform a type of analysis you never predicted, you can, because you never deleted any data.

When you interpret the event stream, you often perform a fold of those events, producing an aggregate result. Sometimes, for efficiency reasons, you do it in advance, and then it's often called a snapshot.

Very closely related to Event Sourcing is the notion of CQRS.