It’s time for bi-temporal event sourcing in part eight of my event sourcing series. In this post, I’ll stick to the basics – at least I hope so. 😅 Bi-temporal event sourcing means that we have two timestamps associated with an event: The first timestamp tells us when the event entered the system, or when the system acquired the knowledge. We call this the application timestamp. The second timestamp states when the event takes effect – the effective timestamp. This is...
Event‑sourced systems must evolve, and sooner or later, events need to change. In the sixth part of my series on event sourcing, we are looking at versioning of events (schemas) and whether migrating or keeping all old versions is the way to go. Of course, there are trade-offs involved regarding long-term maintainability and overall simplicity.
In the fifth part of this event sourcing series, I’ll show you how we use compensation of events to handle failed commands and events that should never have happened. Sometimes, things go wrong – a command fails because the database is overloaded, there is a bug in the code for some edge case, the system is out of memory, the infrastructure misbehaves, etc. Or a user did something that should never have happened, like importing the wrong data set. When this happens, we want the...
This is part three of my event sourcing series. In the first two posts, I showed you approaches that rely solely on projections. Now is the time to introduce read models to support all your query needs. And maybe, solve some performance issues as well. Of course, I’ll discuss the downsides of read models, too.
To finish this post, I’ll do a deep dive into a code example.
This is the first post in a series about event sourcing. I’ll start with a very simple event sourcing implementation that is often good enough. Most of our event streams are implemented in this simple approach. In the following posts, the concepts will be extended to match additional requirements. I’ll touch on read models, consistency, long event streams, archiving, compensation, event skipping, lifetimes, and bi-temporal event sourcing. Every post will explain the concepts and our...
When I open my social media feeds, it is obvious: the age of writing code with our fingers is ending. LLMs and agents can write code much faster.
But was it ever about the speed of source code creation? Was writing code only translating requirements into something the computer can understand?
I think not.
While I generate code with LLMs and agents, creating a piece of code by hand has its benefits. So, this is an ode to “slowly” handcrafted code.
One of the great features of .NET is that you can mix its programming languages (C#, F#, VB.NET) in a single solution and that assemblies written in one language can call assemblies written in other languages. This is great, especially when starting with F#. A team does not need to switch everything at once, but can keep using the existing C# code and use Interop to call C# from F# or vice versa.In this article, we take a look at the Interop story in 2026. Spoilers: it works great.
Not having to annotate types for every argument and return value in F# is a big relief. In this blog post, I share some tips and tricks to reduce the need for type annotations.
We store most of our application’s data in an SQL server database. Sometimes, we need to transfer the data locally to debug defects related to production data. The database grows daily, and restoring the database locally takes more and more time. So we had the idea to disable indices because they are not needed for debugging locally, but restoring them takes quite a lot of time. We can’t disable indices before exporting the data to a bacpac file because it’s the productive...
Yesterday evening, I gave a workshop titled “To test, or not to test” at the Software Crafters Zürich Meetup. In the workshop, we gathered reasons to write tests: being confident that the code works, being confident that regressions can be prevented, helping to drive the implementation, and having documentation of the system. Interestingly, when I prepared the workshop, I forgot about the documentation aspect of the tests. Here is why and why it matters.