Lo que sigue siendo válido en .NET tras 20 años

Llevo casi 20 años escribiendo código en .NET. He visto pasar .NET Framework, el nacimiento de .NET Core, la unificación en .NET 5 y la cadencia anual que nos tiene hoy en .NET 9 con .NET 10 en el horizonte. Muchas cosas han cambiado. Pero hay un núcleo que permanece.

Esto no es una lista de novedades. Es lo que sigue siendo cierto hoy, y que probablemente lo seguirá siendo en otros 20 años.

C# sigue siendo un lenguaje bien diseñado

Cada versión de C# añade algo útil sin romper lo que ya existe. Records, pattern matching, nullable reference types, global usings: todas las incorporaciones de los últimos años hacen el código más expresivo sin forzar paradigmas que no encajan. El equipo de Microsoft tiene criterio. No todo lo que es posible hacer en C# se convierte en feature del lenguaje.

Los principios de arquitectura no caducan

SOLID sigue siendo relevante. DDD sigue siendo relevante. Clean Architecture sigue siendo relevante. No porque sean dogmas, sino porque resuelven problemas reales que cualquier sistema medianamente complejo acaba encontrando: cómo aislar el dominio del negocio, cómo gestionar las dependencias, cómo hacer que el código sea testeable sin gimnasia.

He visto equipos que ignoran estos principios. El coste llega siempre, solo es cuestión de cuándo.

EF Core es suficiente para la mayoría de casos

Cuando empecé, ADO.NET era la norma y Entity Framework era ese ORM que generaba SQL horrible. Hoy EF Core es una herramienta madura, performante y que genera SQL razonable si sabes usarla. No necesitas Dapper para todo. No necesitas escribir SQL a mano por defecto. Úsala bien, entiende qué queries genera y cuándo conviene saltarla.

El logging en producción es trabajo de ingeniería, no un afterthought

Uno de los errores más comunes que he visto: el logging se añade al final, sin estructura, sin contexto, sin pensar en quién lo va a leer cuando algo falle a las 3 de la madrugada. NLog, Serilog, Application Insights: la herramienta importa menos que la disciplina. Logs estructurados, con correlation IDs, con suficiente contexto para diagnosticar sin reproducir el error.

Microservicios no son siempre la respuesta

He trabajado en arquitecturas de microservicios reales, con RabbitMQ, con Azure Service Bus, con el overhead operativo que eso implica. Son potentes cuando el problema los justifica. Pero muchos equipos adoptan microservicios antes de entender su dominio, y luego arrastran una complejidad distribuida innecesaria durante años. Un monolito bien estructurado es una decisión de ingeniería legítima.

.NET MAUI ha madurado

Llevo tres años trabajando con .NET MAUI. Los primeros releases tuvieron problemas serios de estabilidad. Hoy es una plataforma viable para aplicaciones desktop y móvil con una base .NET real. Si tu equipo ya conoce C# y ASP.NET Core, el salto a MAUI es razonable. No es React Native, no compite con Kotlin nativo en performance extremo, pero para la mayoría de aplicaciones empresariales funciona bien.

Lo que ha cambiado de verdad

La velocidad de iteración. Antes esperabas años entre versiones importantes de .NET Framework. Ahora hay una versión nueva cada noviembre. Eso obliga a una postura diferente: no puedes ignorar las actualizaciones durante cinco años y luego migrar. Tienes que mantenerte al día de forma continua, aunque no adoptes todas las novedades.

También ha cambiado el tooling. Docker, CI/CD, GitHub Actions, Azure DevOps: el ecosistema alrededor de .NET es hoy mucho más rico. Un desarrollador .NET que no entiende contenedores ni pipelines de despliegue trabaja con una mano atada a la espalda.

Lo que le diría a otro desarrollador .NET hoy

20 años en .NET me han enseñado que el conocimiento que más dura no es el de las APIs ni los frameworks, sino el de los problemas que la tecnología intenta resolver. Si entiendes por qué existe la inyección de dependencias, por qué importa separar el dominio de la infraestructura, por qué el logging estructurado es crítico en producción, estarás en buena forma independientemente de qué versión de .NET uses.

El lenguaje ha cambiado mucho. Los problemas fundamentales, mucho menos.

Si tienes delante alguno de estos problemas y te vendría bien hablarlo con alguien que ya los ha resuelto, hago refuerzo técnico y mentoring con equipos y desarrolladores que están en ese punto.