DRY Is the Most Misunderstood Rule in Programming
DRY was never about code that looks the same. It's about knowledge. Most of the tangled abstractions I've had to unwind started as a well-meaning atte...
Page 3 of 22. Practical .NET and software architecture lessons.
DRY was never about code that looks the same. It's about knowledge. Most of the tangled abstractions I've had to unwind started as a well-meaning atte...
For years we faked union types with marker interfaces, base classes, and the OneOf library. C# 15 finally bakes them into the language - and here's a ...
When a single API call takes minutes to finish, it punishes both your users and your server. Here's the progression I walk through to turn long-runnin...
A use case isn't a transaction. The moment it touches more than one system, you are dealing with partial failure. Here's how I classify side effects a...
Most teams reach for v2 too early because they don't have a contract evolution strategy. Here's the API change management approach I prefer: evolve co...
Most 'DDD-ish' code I review enforces business rules everywhere except in the model itself, so the same rule ends up duplicated across handlers and va...
The test pyramid made sense when integration tests meant a shared database server and a 20-minute build. It doesn't match how I build .NET systems in ...
I resisted primary constructors for a while. They felt like a shortcut that would cost me later. But after using them across several projects, I'm sol...
Long-running business processes don't fit neatly into a single request. Wolverine's Saga support gives you a convention-based approach to orchestratin...
The Outbox pattern guarantees reliable publishing. But what about the consumer side? The Inbox pattern ensures each incoming message is processed exac...
Join 66,000+ readers of The .NET Weekly for practical tips and resources to improve your .NET and software architecture skills.