Observability has been one of the hot topics, with the increasing complexity of knowing what is going on in our applications. Fortunately, .NET has been investing in making things easier with OpenTelemetry.
Making use of the type system is something I feel should be important when working in a strongly typed language like C#. However, I don’t feel like that’s the case, and I would love for the language to push folks in the direction of creating more robust programs, where the compiler provides more help in proving the correctness of the code.
I’ve been trying to flee the over-engineered C# solution structures, with multiple projects, with related code scattered around. Even if an imperfect solution, I’ve turned to NetArchTest to help in guide on following some conventions in a simplified solution structure.
On the topics of domain-driven design and event-driven architecture, something that’s been on my mind for quite some time, is the process of handling domain events, as well as potentially translating them into integration events.
Recently there was a need to use a hierarchy in a domain model, and there was a question about which of the available approaches to use - table per hierarchy (TPH), table per type (TPT) or table per concrete type (TPC). This very brief post is just a quick look at some benchmarks I created on the subject.
This will be a very brief post, just as a reminder that we need to give things a good thought, trying to limit our biases (I’ll focus on software development, but it’s applicable to everything really).
In C# and .NET land, we’re pretty heavy on the code first approaches, with the odd exception. Let’s take a look at a possible contract first approach to API development, with OpenAPI, but still taking advantage of existing tooling that we’ve come to rely on, like Swagger UI.
I’m pretty late to the C# source generator party, but hey, better late than never 😅. In this post, let’s take a look at how we can automagically map minimal API endpoints using C# source generators
The boxes developers put themselves into is something I’ve given some thought over time. Probably not something folks think about much, but figured I’d write a post about it anyway.
I’ve had some of thoughts not exactly résumé-driven development, but more importantly, how engineers, can remain up to date and relevant in the job market, and a recent discussion on LinkedIn reminded me about it.