I have been digging into MartenDb and found a sample of the Event Sourcing features included in MartenDb. In this article I walk through this simple Event Sourcing example and describe what is happening.

In today's rapidly evolving business landscape, traditional linear business models are being disrupted by the emergence of platforms. Platform thinking offers a new paradigm for businesses to unlock their potential, create scalable ecosystems, and drive innovation. In this article, we will delve into the world of platform thinking, exploring its benefits and highlighting why businesses should consider adopting this strategic approach.

I recently stumbled upon a Library called FastEndpoints while doing research and it immediately struck me as something I wanted to learn more about. I had started experimenting with Minimal APIs at the time. While I liked that Minimal APIs lower the entry point for simple API creation and are significantly more performant than MVC Controllers, they quickly turn your program.cs file into a jumbled mess with anything beyond trivial. The desire for code organization quickly pushes towards finding a sensible way to orient the code.

Not versioning APIs is one of the biggest issues I see with teams that attempt to implement a distributed architecture. Not supporting multiple versions of an API means all the teams are coupled together and requires downtime to deploy. I've actually seen where this is actually listed as a reason to use a monolith instead of a distributed architecture.

Recently, I became aware of two other options in the .NET Service Bus space that I felt deserved a closer look. Rebus and Brighter. Since Rebus seemed to be similar to NServiceBus and MassTransit I started there.

One of the most painful parts of starting with a new team is to learn all of the nuanced patterns and practices you must adhere to. Often these nuances are not documented and to make matters worse, the common response given for why is, "that is just how we do it here". The tribal knowledge runs so deep it starts to look like cargo cult culture and in some cases it is just that.

The role of Software Architect is typically not well defined in most organizations and I've found Gregor Hohpe's description of The Architect Elevator to be the most enlightening.

Change is hard as a individual. Implementing lasting change in a team or organization is probably one of the most difficult things one can attempt. I say lasting change, because it is easy to impose short term change, but hard to make that change stick.

Dr. Eliyahu M. Goldratt, author of The Goal and father of the Theory of Constrain identified Four questions necessary to realize the full benefits of adopting a new technology. These Four questions can be used to help your organization realize order of magnitude advantages when adopting new technologies like the Cloud.

As a software engineers we all know the requirements will change over time. At some point you will need to become comfortable with versioning your NServiceBus messages to adapt to those changing requirements. When you start thinking about the nuances of deploying endpoints that need to handle messages of different versions in flight or in an error queue waiting for retries it can be overwhelming at first. Luckily, there is a straight forward and relatively painless way to make changes to your contracts that will enable your endpoints to process old and new versions in parallel.