Do you love accounting just that much as I do?

You do? Well, I guess we all have our flaws. To be honest: I hate accounting. And I am very happy that there are people I can pay for to handle this for me.

But there is one thing I really admire: They know a lot about a decent way of engineering that I had to learn the hard way.

There is only one rule

There is one rule in accounting. Accountants use ballpoint.

No edits. Something that happened, even if by mistake, remains in the books. There is no editing. There is only appending.

To get a wrong entry fixed, you will have to create a new entry in order to get the desired state.

But why is that something you should bother? You are - most probably - not in accounting and not even in financial software development.

I'll tell you: Accountants can get to a specific state on every time based on their append only logs.

By design, if you start with a balance of 0€, adding 10€, remove 5€ again, you will end up at 5€ balance. And you know about the balance of an account at any given time.

With that series of entries stored in a simple excel file, written down using pen and paper, whether you used papyrus or clay tablets. It is always possible to get the balance at any given time.

And as you already recognized correctly: If you know the initial balance, you do not even need that "Balance" row. It is easy to calculate the balance in your head.

You did a mistake? No problem, just create another entry that fixes it:

Easy, right?

But still: Why am I telling you all this?

Sometimes, past state is important

When it comes to software, we are used to store state in the database. It is, what it is. It is the current state. Sure, some of you added something like an activity log or versions and revisions. But still, this represents something that is "there".

And there is nothing wrong with it. Unless you might wonder one day: Why is it the way it is?

Or even try to answer questions you never thought about when designing that database schema and your models.

Questions that can come up could be:

• How often added a customer a product to the cart, but removed it or decreased quantity just before checkout?
• How long was Thomas part of that project in that app?
• Did the user delete that post or is there something wrong in our migration?

You can answer some of those questions. It can require some raw SQL queries. But sometimes you are just missing data.

And this is, where eventsourcing shines and suddenly this post just starts to make sense. Of course, my accounting example is, besides being booooring, a bad one, because event sourcing is not only about balances and accounting.

Think about this stream of events:

Okay. Now we are getting somewhere. But this raises a question: Why?

If I write down all these events, I would be able to answer questions about it without knowing the need of answering those questions at that time.

I could answer: How many coffee do you drink per day? Which days are the ones with the highest coffee consumption? At what time do I usually leave the house?

Of course, I would not really write such a log in real life. But there are certain cases I'd opt in for event sourcing - besides working in finances.

The eventstream-series

So let's take this thought and build on it. On this publication, I will add a small series of posts about my learnings on an event sourced systems with huge ambitions and a ton of learnings.

eventsourcing - building #neuland

Enter the event stream with me. In this series I will share my attempts, failures, learnings and big wins of my event sourcing journey. Be prepared for hours of boredom - or, if you like to revisit existing patterns - hopefully some enlightening moments.

building #neulandRoman