Dotnet on Patrones — Exeal

API Lite: un segundo host con infraestructura en memoria

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Un frontend (o una suite de Playwright) que depende del backend real para poder trabajar arrastra todos los problemas del backend real: hay que levantar Postgres, colas, un proveedor OIDC, a veces Hangfire o un bucket S3, y el estado se acumula entre ejecuciones. Para tocar UI esto es fricción pura — nadie necesita persistencia real para ver si un botón pinta bien. Para tests de extremo a extremo es peor: los tests dejan de ser deterministas (dependen de datos que quedaron de ejecuciones anteriores, de latencia real contra servicios externos, de que Postgres/Hangfire arranquen a tiempo) y se vuelven lentos de levantar y frágiles de mantener.

Arquitectura hexagonal (puertos y adaptadores) en .NET

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando la lógica de aplicación y la infraestructura (base de datos, storage, proveedores externos) conviven en el mismo proyecto, es fácil que un caso de uso acabe llamando directamente a un DbContext, un cliente HTTP o HttpContext. El código compila, funciona, pero deja de ser unit-testable: cualquier test de un caso de uso arrastra un contenedor de base de datos o un mock del framework web. Con el tiempo esto también acopla el dominio a decisiones de infraestructura que deberían poder cambiar solas — cambiar de ORM, servir el mismo core desde dos hosts distintos (uno con infraestructura real y otro en memoria para tests de frontend), o simplemente entender qué necesita realmente un caso de uso del mundo exterior.

CLI de seed de escenarios de prueba contra base de datos local

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Un sistema con varias máquinas de estado (un pedido, un cobro, una verificación de identidad…) tiene decenas de combinaciones de estado posibles, y muchas de ellas dependen de integraciones externas (una pasarela de pago, un proveedor de scoring, un servicio de verificación) que tardan, cuestan o simplemente no se pueden disparar a demanda en local. Para llegar a probar a mano un caso concreto — por ejemplo, un pedido rechazado por scoring, o uno con la verificación de dirección fallida — habría que arrastrar un pedido real por todo el flujo: crearlo, esperar la respuesta del proveedor de turno, forzar el caso concreto que se quiere ver.

Comandos de mantenimiento en apps .NET

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Tarde o temprano toda API con un composition root no trivial (DI container, configuración por entorno, logging estructurado) necesita ejecutar una tarea de mantenimiento puntual: un backfill, recalcular una agregación, purgar registros huérfanos, deduplicar datos tras un bug. Esto no es solo leer o escribir filas: a menudo hay que invocar los mismos servicios de dominio que la app usa para garantizar sus invariantes (un agregador, un motor de fusión de duplicados, un validador), en vez de reimplementar su lógica en un script.

Gestión de errores explícita con un Result tipado

Thu, 24 Sep 2026 00:00:00 +0000

Problema

En un caso de uso hay dos tipos de “fallo” completamente distintos, y usar excepciones para ambos los mezcla en el mismo mecanismo: “crédito denegado” o “el email ya está registrado” son resultados esperados del dominio — pasan en producción todos los días y el código que llama al caso de uso tiene que decidir qué hacer con ellos — mientras que “la base de datos no responde” o “el proveedor de scoring ha dado timeout” son fallos de infraestructura que no le competen al dominio decidir, solo propagar para que alguien reintente o salte una alerta.

Host fino y módulos deep

Thu, 24 Sep 2026 00:00:00 +0000

Problema

A medida que una aplicación crece, es fácil que todo acabe en un único proyecto (o en una pila de proyectos sin fronteras reales) donde cualquier clase puede llamar a cualquier otra. El resultado son dos problemas que se retroalimentan:

No se puede razonar ni testear una pieza en aislamiento. Para validar la lógica de un caso de uso hace falta levantar medio sistema, porque nada impide que esa lógica dependa de detalles internos de otra parte de la aplicación.
Una IA (o una persona nueva) que trabaja sobre una funcionalidad concreta necesita cargar contexto de todo el sistema para saber qué es seguro tocar y qué no, porque la superficie pública y la implementación interna son indistinguibles a simple vista.

Esto se agrava en aplicaciones con piezas muy distintas entre sí: un listener de webhooks, una API administrativa, lógica de negocio con jobs en background. Cada una tiene su propia complejidad interna, pero todas acaban compartiendo el mismo espacio de nombres sin fronteras que el compilador conozca.

Snapshot de contrato OpenAPI aceptado explícitamente

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Cuando el contrato HTTP de una API se genera automáticamente a partir del código (controladores, DTOs, atributos), nadie lo “escribe” a mano — y por eso nadie lo revisa a propósito tampoco. Un refactor interno que renombra un campo, cambia su tipo, o hace opcional algo que antes era obligatorio, cambia el contrato público como efecto secundario silencioso: compila, los tests unitarios pasan, y el PR se fusiona sin que nadie haya mirado el swagger. El consumidor de esa API (un frontend, otro servicio, un cliente externo) se entera cuando algo se rompe en producción, no en la revisión del cambio.

Tests de aceptación de backend sobre una imagen Docker ya construida

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Un backend .NET no se despliega como código fuente: se despliega como imagen Docker. Entre el código que pasa los tests unitarios y la imagen que corre en producción hay una capa entera que ningún test contra el código fuente toca — el Dockerfile, las variables de entorno que el contenedor espera recibir, si el puerto publicado es el correcto, si las migraciones corren al arrancar, si el healthcheck responde. Un WebApplicationFactory o un test de integración que arranca la app in-process compila contra las mismas clases que ya se probaron, así que no puede detectar ninguno de esos fallos — están todos fuera del código, en el empaquetado.

Tests de persistencia del repositorio real

Thu, 24 Sep 2026 00:00:00 +0000

Problema

Con el patrón Repositorio, la lógica de negocio se testea contra una implementación fake en memoria del repositorio: rápida, sin dependencias externas, perfecta para cubrir reglas de negocio con muchos casos. El problema es que esos tests solo prueban la lógica de negocio — nunca ejercitan la implementación real del repositorio, la que de verdad habla con la base de datos en producción.

Eso deja un hueco concreto: una query LINQ que EF Core no puede traducir a SQL y falla en tiempo de ejecución, un GroupBy/Join/Distinct que en memoria cuenta bien porque ejecuta el mismo predicado C# pero en SQL agrupa distinto, una constraint única que en producción vive en el esquema de la base de datos pero que el fake in-memory no reproduce porque no impone ninguna unicidad, una condición de carrera que solo se resuelve con un INSERT ... ON CONFLICT real. Nada de esto puede fallar en un test contra el fake, porque el fake y la implementación real solo comparten la interfaz — su comportamiento interno es completamente distinto. El fake existe justamente para no pagar el coste de hablar con una base de datos real en cada test de negocio, así que por construcción no puede detectar estos fallos.