In the fourth part of my event sourcing series, we’ll take a look at why long event streams – streams with lots of events – are a problem and what options there are to deal with this problem. Why read models are not always enough to solve performance issues due to long event streams. And of course, I’ll discuss the involved trade-offs.
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 second post in my series on event sourcing. Last time, we saw a simple implementation based only on projections. While simple, it can only be queried by the event stream ID. In this post, we look at an approach that allows for more lookup criteria while still avoiding a read model.
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...
We started using event sourcing over ten years ago. One of the hardest lessons was that there is a kind of events that is not obvious at first but have a big impact on your system design. I call this kind secondary domain events.
In this post, I’ll explain what secondary domain events are, and how they impact the design.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In the final part, we examine how LLMs affect testing and conclude the series.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this part, we look at how to make manual testing easier and why it matters.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.
In this post, we look at what we can do to recover well even if a defect finds its way into production.
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are. In this part: What would you do if you weren’t allowed to write automated tests? Take a moment and think about what you would do to still deliver quality software if you weren’t allowed to write automated tests. I...
I wrote code without tests that ran in production without defects, and I wrote buggy code with TDD (Test Driven Development). Time to look back at 35 years of coding and when tests help, and when there is something better. And especially, what these better things are.