Arquitectura
Arquitectura hexagonal vs en capas
Las dos compilan. Las dos entregan. La diferencia no se ve el día uno. Se ve el año tres, cuando la lógica de negocio está soldada al framework y a la base de datos y nadie puede cambiar una sin romper las otras.
Qué te da “en capas”
Controladores, servicios, repositorios: rápido de arrancar y familiar. Pero el dominio acaba importando JPA, Spring y la capa web, así que tus reglas de negocio no se pueden testear, reutilizar ni razonar sin todo el stack alrededor.
Lo que cuesta al tercer año
Cuando el dominio importa JPA, Spring y la web, un cambio en cualquiera de ellos alcanza tus reglas de negocio. No puedes testear una regla en unidad sin arrancar todo el stack, una columna nueva se propaga hacia fuera, y el onboarding significa entenderlo todo a la vez. La arquitectura en capas casi nunca falla en la revisión de diseño; falla en la entidad número 200, con una deadline encima, cuando el acoplamiento ya está por todas partes.
Qué cambia hexagonal
Puertos y adaptadores: el dominio tiene cero dependencias de framework, y la base de datos, el framework y el mecanismo de entrega pasan a ser detalles intercambiables tras puertos. Cada entidad es un vertical slice autocontenido:
- Dominio — la entidad y sus reglas, Java plano sin imports de Spring, JPA ni web. Testeable en aislamiento.
- Aplicación — los casos de uso, que llegan al exterior solo a través de puertos (interfaces que posee el dominio).
- Infraestructura — los adaptadores tras esos puertos: persistencia, el controlador HTTP, la mensajería. Intercambiables sin tocar el núcleo.
La frontera se impone, no se espera
Esto no es una convención de nombres que esperas que la gente respete. Reglas ArchUnit vienen dentro de la suite de tests y hacen fallar el build si el dominio tira del framework, o una capa importa a través de una frontera que no debería. El hexágono sigue siendo un hexágono, build tras build.
Si conoces Spring Modulith
Mismo objetivo, por otro camino. Spring Modulith impone fronteras de módulo dentro de un monolito; aquí cada entidad ya es un slice autocontenido con el dominio aislado, y ArchUnit mantiene esas fronteras honestas en CI. Los mismos módulos se entregan como monolito modular o como microservicios, así que tienes la disciplina de fronteras sin comprometerte de antemano con una forma de ejecución.
Por qué los generadores suelen producir CRUD por capas
Porque es el camino de menor resistencia, y los equipos asistidos por IA derivan a él bajo presión de plazos. AlveoForge hace lo contrario por construcción: hexagonal real con vertical slicing, igual siempre, así la arquitectura no puede degradarse en silencio a MVC con nombres de carpeta hexagonales.