Oskar Dudycz

Pragmatic about programming

Introduction to Event Sourcing - Self Paced Kit

Start learning Event Sourcing through practical exercises that build from defining events and rebuilding state to handling business logic, concurrency, and projections.

2022-03-16 oskar dudyczEvent Sourcing

cover

For many developers, Event Sourcing is like a Nessie, most of them have heard of it, but not many have seen it. I was one of them. I started my journey with Event Sourcing over five years ago. Practical journey: Before that, I mostly read books, which shouldn’t count. Why? Because there were few of them showing how to apply Event Sourcing practically. When my colleague said, “well, you’re doing a financial system then Event Sourcing sounds like a good match”, I was curious. Then I was thrilled, as finally, I could use the pattern known from the books. I used Marten library. The first steps were hard. I was irritated. I started to get doubts if that was something for me.

I’m not the type of person to easily give up. Step by step, I understood more and more. After making mistakes and learning from them, I got a better vision. I noticed Marten has some missing pieces, so I sent pull requests. I also began interacting with users on the Gitter channel because they had the same struggles. Then I became a co-maintainer.

That’s what I wrote 1.5 years ago in my post Revolution now!. I wrote it when I joined EventStoreDB as a Developer Advocate. That allowed me to have experience working with two different approaches to Event Sourcing and working with those two communities. There are also different shades, Domain-Driven, Object-Oriented, Functional techniques. You can do Event Sourcing in plenty of different ways. Yet, that’s not easy when you’re starting. The lack of resources motivated me to work on my sample repository Event Sourcing in .NET which grew into an extensive compendium. I also started to do spin-off repositories:

One of the reasons is that I continue to learn to play in different ways, plus I’d like to cherish my dumbness, so I stay close to the people starting their journey. I believe that Event Sourcing is a pretty practical and straightforward concept. It helps build predictable applications closer to business. Nowadays, storage is cheap, and information is priceless. In Event Sourcing, no data is lost. Yet, it takes work to learn. My goal is to make it more accessible.

Recently, I’ve been doing another private training, and as a side effect, I created a set of exercises together with suggested solutions that explain foundational concepts step by step:

  1. Events definition.
  2. Getting State from events.
  3. Appending Events:
  4. Business logic (aggregates, command handlers, OOP vs Functional).
  5. Optimistic Concurrency.
  6. Projections (General approach, dealing with Idempotency and Eventual Consistency).

That shows the practical aspects of using Event Sourcing with different toolings like Marten and EventStoreDB.

I decided to open-source them to allow people to do them as a self-paced kit. Get it here:

It took me two weeks of full focus, plus all the hours I spent in the past years. Of course, it’s not the same experience as attending the workshop. But it should be a decent starting point in your Event Sourcing journey. It should give you the tools to build on and play with your ideas and reduce the initial confusion.

If you need more than that and want full coverage with all nuances of the private workshop, check the training page. Feel invited to contact me via email.

I plan to extend it and provide similar exercises in other languages when I find enough time. Contact me if you want to sponsor such an effort and make that happen for your favourite tech stack.

If you like it, share it with your friends to benefit.

Drop me also a line with your thoughts!

Cheers!

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar