Introducción a la Arquitectura Hexagonal con Spring Boot

Sobre el curso

En tres clases construyes una aplicación Spring Boot con arquitectura hexagonal desde el proyecto vacío, 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 depende de ningún módulo ni de Spring; después reservas-application, que solo depende del dominio; y al final los adaptadores, que dependen de todo lo anterior. Con módulos Maven esa regla no es una convención: la obliga el build. Si alguien intenta usar jakarta.persistence o @Service dentro del dominio, no compila, porque esas clases no están en su classpath. 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 Spring Data JPA sobre H2 modificando una línea de BeansConfig: el dominio y la aplicación no se tocan y los tests siguen pasando. Esa es la comprobación final de las tres clases. Hay un punto que solo se puede enseñar con base de datos de verdad: la entidad de dominio y la entidad de JPA no son la misma clase. ReservaEntity tiene @Entity, @Id, nombres de columna, constructor sin argumentos y setters —los que Hibernate exige—; Reserva tiene reglas, y por eso mismo no puede tener constructor vacío ni setters. Ponerle @Entity al dominio es exactamente lo que fuerza el dominio anémico. Entre las dos hay un mapper, en infraestructura. 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 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 contexto de Spring ni 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 Flyway ni migraciones en producción, índices ni tuning, y no hay Spring Security, WebFlux, despliegue ni revisión del proyecto propio.

Lo que vas a aprender

• Construir las tres capas —dominio, aplicación e infraestructura— desde el proyecto vacío, con un módulo Maven por capa
• 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: sin extender JpaRepository ni devolver entidades de JPA, Page o Specification
• Implementar dos adaptadores del mismo puerto: in-memory y Spring Data JPA sobre H2
• Probar el dominio y el caso de uso con JUnit 5, sin @SpringBootTest y sin base de datos
• Comprobar con el build de Maven que las dependencias entre módulos apuntan hacia adentro
• Entender por qué la entidad de dominio y la @Entity de JPA 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