Hey estimados devs, aquí continuaré dando respuesta a las preguntas planteadas en este artículo.

Categoría 2: Patrones, principios y arquitectura

5. Explica el concepto de Dependency Injection en .NET y por qué es importante.

DI es un patrón donde las dependencias se inyectan en lugar de crearse dentro de las clases.

A diferencia de .NET Framework, en .NET Core (conocido como .NET desde la versión 5 en adelante) viene nativo: registras contratos e implementaciones como por ejemplo:

services.AddScoped<IMailer, SendGridMailer>();

Así recibes lo que necesitas por el constructor.

Con esto reduces el acoplamiento y haces que tu código sea testeable, ya que en los tests registras FakeMailer que implementa la interfaz IMailer.

Ejemplo real: un endpoint que envía correos no conoce SmtpClient ni SendGrid; solo conoce IMailer. Cambiar a otro proveedor o simularlo en pruebas es solo cambiar el registro en el contenedor, no el código del endpoint.

6. ¿Cómo implementarías Clean Architecture en un proyecto .NET real?

Separa el proyecto en capas con dependencias hacia el dominio.

Cada capa da lugar a un proyecto en la solución, y tendríamos:

• Domain (donde están tus entidades, value objects, eventos),
• Application (casos de uso, validaciones, puertos),
• Infrastructure (EF Core, email, cache, Files, Azure/AWS), y
• Web/API (controladores/Minimal APIs).

Web y Infrastructure dependen de Application/Domain, nunca al revés.

Recuerda el diagrama de Clean architecture 😉

7. ¿Qué patrones de diseño aplicas con frecuencia en proyectos .NET y por qué?

En .NET es muy común usar Strategy cuando necesitas cambiar el comportamiento según el contexto, por ejemplo un servicio de impuestos que aplica distintas reglas por país (ITaxStrategy → PeruTax, UsTax).

El Repository y el Unit of Work se aplican para encapsular el acceso a datos y mantener transacciones, aunque en muchos casos EF Core ya implementa gran parte de esto, así que se usan más cuando quieres unificar la lógica de consultas o abstraer la persistencia.

El Options Pattern y el Configuration Pattern son claves en ASP.NET Core para manejar configuraciones externas sin acoplarlas al código. En el caso de Configuration es especialmente útil con Entity Framework Core.

El Mediator (con MediatR) ayuda a organizar comandos y queries en aplicaciones complejas, evitando que los controladores conozcan demasiada lógica. El patrón Factory es útil cuando necesitas crear objetos con lógica de inicialización compleja, como por ejemplo tener distintos proveedores de pago.

Finalmente, el Circuit Breaker (implementado normalmente con Polly) protege tus servicios de fallos repetidos en llamadas externas, evitando sobrecargar sistemas caídos y aumentando la resiliencia.

Podrías añadir al final que en resumen, estos patrones no son “decoración” sino que ayudan a mantener el código más limpio, desacoplado, configurable y resiliente, lo que se traduce en aplicaciones .NET más fáciles de probar, mantener y evolucionar.

8. ¿Cuál es la diferencia entre un microservicio en .NET y un monolito modular?

Un microservicio es un bounded context desplegable de forma independiente, con base de datos propia, expuesto vía HTTP/gRPC y con observabilidad, resiliencia (Polly), mensajería y versionado. Gana independencia y escalado por servicio, pero pagas complejidad: orquestación, tracing distribuido, seguridad entre servicios, datos duplicados y sagas para transacciones.

En cambio, un monolito modular tiene módulos bien aislados (catálogo, órdenes, pagos) dentro de un mismo despliegue y DB compartida o esquemas separados. Es más simple de operar y más fácil de depurar; rinde muy bien. Si lo diseñas con límites claros (feature folders, módulos, eventos internos), puede evolucionar luego a microservicios.

9. Más allá de Clean/Onion/Hexagonal, ¿cómo decides entre un enfoque por capas, vertical slices o CQRS/MediatR? ¿Cuáles son las ventajas y desventajas de cada uno?

Capas clásicas (Controllers → Services → Repos): aprendizaje fácil y bueno para CRUD, pero tienden al modelo anémico y a módulos muy acoplados con el tiempo.

Vertical Slices: organizas por feature (Carritos, Orders, Customers, Products) con su propio handler, modelo y validación. Reduce el acoplamiento y la mala praxis “god class” ya que incentiva la responsabilidad única (Single responsibility de SOLID). Ideal para equipos que iteran rápido y dominios cambiantes.

CQRS/MediatR: separa lecturas de escrituras; útil cuando las lecturas y escrituras escalan distinto o necesitan modelos diferentes y caché agresivo. Como desventaja podrías mencionar que tiene más complejidad (handlers, mapeos, potencial Event Sourcing).

Puedes mencionar esta regla simple pero efectiva: empieza con Vertical Slices; añade CQRS solo cuando la presión de rendimiento/escala o reglas de lectura/escritura lo justifiquen.

10.  ¿Qué es el Teorema CAP y cómo influye en el diseño de sistemas distribuidos en .NET?

Para esta pregunta te recomiendo leer mi artículo.

El teorema CAP dice que, cuando hay una partición de red (P de Partition) un sistema distribuido debe elegir entre dos cosas:

Una partición de red es un fallo en la comunicación entre nodos o microservicios.

• Consistencia (C de consistency): que todos vean los mismos datos al mismo tiempo.
• Disponibilidad (A de availability): que el sistema siempre responda, aunque sea con datos desactualizados.

No es posible garantizar ambas al mismo tiempo si hay una partición.

Recuerda que P no se puede evitar en sistemas distribuidos.

👉 En .NET, esto se refleja en cómo eliges tus almacenes de datos y patrones:

• Si priorizas Consistencia (CP), como en SQL Server con réplica síncrona, algunas operaciones se rechazarán cuando haya fallos de red.
• Si priorizas Disponibilidad (AP), aceptas escrituras aunque los datos tarden en sincronizarse. Aquí se usan patrones como eventual consistency, Outbox + Kafka/RabbitMQ, reintentos con Polly o Sagas para compensaciones.
• Bases modernas como Azure Cosmos DB te permiten configurar el nivel de consistencia, por ejemplo: fuerte para operaciones críticas y eventual para lecturas masivas donde importa más la velocidad que la exactitud inmediata.

Esto es todo por ahora, dev, en la siguiente entrada seguimos con la siguiente categoría! 👌🏼

¡Si esta entrada te ha gustado, compártela! 

Créditos de imagen de portada: Basado en Foto de Gerald Schömbs en Unsplash