February 16, 2024
I feel events are used too many times as a hammer to dismantle coupling. Unfortunately, it's gold plating. It might look better, but it'll fire back in the long term and cost more.
Too many times, Event Sourcing is presented as the natural companion to CQRS. That's not the case. CQRS doesn't dictate using Event Sourcing. Let's see why.
NServiceBus endpoints support only code-based configuration, which is handy and not always friendly at the same time. But what if we could plug in the superb Microsoft configuration extensions to configure NServiceBus endpoints?
In a message-based system, we might feel a lack of control, especially when in need of compensating changes spread across the system. Fear not! Real life deals with compensation every day! And it's better than rolling back a transaction or deleting some data in the database.
.NET developers building message-based systems seem to give serialization and surrounding concerns more importance than needed. Let's try to dissect the topic
There are scenarios when a chatty services relationship seems the only option, with the results of coupling quickly becoming our best friend. Not all hope is lost, we can try to ask different questions to untangle the knot.
There are scenarios where updating data is either forbidden by policies or undesirable because it hinders the ability to fulfill other requirements. That is when append-only models come to the rescue.