
Gabriel Marinho
152 posts









The hidden cost of "enterprise" .NET architecture: Debugging hell. I've spent 13+ years in .NET codebases, and I keep seeing the same pattern: Teams add layers upon layers, to solve the problems they don't have. IUserService calls IUserRepository. IUserRepository wraps IUserDataAccess. IUserDataAccess calls IUserQueryBuilder. IUserQueryBuilder finally hits the database. I've seen a lot of classes having one-line methods whose sole purpose was to call the next layer and that's it. But to change one validation rule, you step through 5 layers. To fix a bug, you open 7 files. The justification is always the same: "What if we need to swap out Entity Framework?" "What if we switch databases?" "What if we need multiple implementations?" What if this, what if that. The reality: Those "what ifs" don't come to life in 99% of cases. I haven't worked on a project where we had to swap the ORM. But I've seen dozens of developers waste hours navigating through abstraction mazes. This happens with both new and experienced developers. New developers asking on Slack all the time: "Where to put this new piece of code?" But senior developers are too busy to answer that message. Why? Because they are debugging through the code that has more layers than a wedding cake. The end result? You spend more time navigating than building. Good abstractions hide complexity. Bad abstractions ARE the complexity. And most enterprise .NET apps? Way too much of the second kind.






Com -3 °C, Santa Catarina registra a menor temperatura de 2026 glo.bo/4eTIXN0 #g1














