This is a tale of a good amount of hours of wasted time, so I鈥檓 going to document it so I remember it in the future. The idea is simple: when building an API, how can we treat a complex type as a simple type, to avoid things like primitive obsession, implement strongly typed ids and other related patterns? Let鈥檚 find out! 馃檪
In this episode, we鈥檒l implement the outbox publisher, or better yet, two versions of it, one better suited for lower latency and another for reliability. As we continue our event-driven path, this will be a good opportunity to introduce a couple of interesting .NET Core features: IHostedService (and BackgroundService) and System.Threading.Channels.
On the footsteps of the last episode, in this one we store the inferred events in the outbox table, doing so transactionally, so we have guarantees that any change will eventually result in a published event.
In this first step implementing event-driven integration between services, we鈥檒l hook-up into EF Core鈥檚 infrastructure, namely when saving changes, to infer if any event should be raised based on the information provided by the change tracker.
As we start implementing event-driven integration, the first thing we need to do is publish the events. Although it might seem straightforward, there are some important things to consider in order to make it work reliably. In this episode, we discuss the challenges and introduce the transactional outbox pattern to help us facing these challenges.
In this episode, we take a look at the integration problem we have between services right now, go through some options to avoid or fix it, then have a quick overview of the solution we鈥檒l be implementing in the coming episodes.
Following up on the last episode about the Optional type, we continue taking inspiration from functional languages and introduce Either and Error types, as a way to make the possible business logic outcomes more explicit and minimize using exceptions in non-exceptional situations.
In this post, we鈥檒l make use of a concept most commonly associated with functional programming, the Optional type (aka Option or Maybe), in order to make our code safer and more explicit when expressing a lack of value, instead of leaning on the null reference, something that I鈥檓 sure has burned us many times in the past.
In this episode, we鈥檒l make things more object oriented, by moving some logic that鈥檚 present in the request handlers, which in fact should be present in the domain entities, that currently are just bags of data with public getters and setters.
In this episode, we鈥檒l take a look at (yet) another approach to organizing data access code, very likely overkill.