Introducción a la Arquitectura Hexagonal con .NET

Sobre el curso

En tres clases construyes una aplicación .NET con arquitectura hexagonal desde la solución vacía, y entiendes de quién es cada responsabilidad porque escribiste cada capa por separado, en el orden en que las capas dependen unas de otras. No se refactoriza nada. La arquitectura no se presenta como el arreglo de un código malo: se construye directamente bien, empezando por el centro. El código plano aparece solo al principio, diez minutos, ya escrito y a modo de contraste. El orden de construcción es la lección: primero Reservas.Domain, que no referencia ningún proyecto; después Reservas.Application, que solo referencia al dominio; y al final los adaptadores, que referencian todo lo anterior. En .NET esa regla no es una convención: es algo que el compilador obliga. Si alguien intenta usar EF Core dentro del dominio, no compila. El caso es mínimo a propósito: reservas de sala. Se eligió porque tiene dos reglas de negocio de naturaleza distinta —una que la reserva puede responder sola y otra que necesita ir a ver las demás—, y esa diferencia es exactamente la que enseña dónde va cada cosa. Al terminar la clase 2 la aplicación ya funciona y está probada, y todavía no existe ni un endpoint ni una tabla. En la clase 3 se cambia el adaptador in-memory por EF Core sobre SQLite modificando una línea de Program.cs: Domain y Application no se tocan y los tests siguen pasando. Esa es la comprobación final de las tres clases. Encuadre, para que nadie llegue esperando otra cosa: esto es hexagonal en tres capas, puertos y adaptadores. No es el esquema de los cuatro anillos de Uncle Bob con Input/Output Ports y Presenters — eso es el taller de .NET 10 + Clean Architecture, que continúa desde acá. Qué te llevas: el repositorio con la construcción paso a paso (un commit por capa), el ejemplo plano como material de contraste, los tests que corren sin base de datos, una hoja de una página con el checklist «¿de qué capa es esto?», las grabaciones y el diploma de participación. Qué NO incluye, dicho antes de vender: no hay ejercicio de refactorización (es deliberado), no es Clean Architecture completa ni DDD, no se cubren migraciones en producción ni tuning de base de datos, y no hay autenticación, despliegue ni revisión del proyecto propio.

Lo que vas a aprender

• Construir las tres capas —Domain, Application e Infrastructure— desde la solución vacía
• Saber repartir una regla de negocio: qué va en la entidad y qué en el caso de uso, y por qué
• Escribir un value object (record) y una entidad que nacen válidos y protegen su invariante
• Declarar un puerto sin filtrar la base de datos en su firma: ni IQueryable, ni DbSet, ni entidades de EF
• Implementar dos adaptadores del mismo puerto: in-memory y EF Core sobre SQLite
• Probar el dominio y el caso de uso con xUnit, sin host web y sin base de datos
• Comprobar con el compilador que las referencias entre proyectos apuntan hacia adentro
• Entender por qué la entidad de dominio y la de persistencia no son la misma clase, y qué hace el mapper
• Reconocer los cuatro errores típicos y distinguir cuándo NO vale la pena aplicar esto

Programa del curso

3 módulos · 6 horas en total