La misma Todo App en hexagonal y en un solo fichero: ¿cuál prefiere una IA?
La misma Todo App (Java 21 / Spring Boot 3) escrita dos veces: con arquitectura hexagonal + DDD y como un único fichero pensado para agentes de IA. Mismo stack, misma API y mismos casos de uso; lo único que cambia es cómo se reparte el código — y cuánto cuesta en tokens.
Contexto
La arquitectura hexagonal con DDD es casi un dogma para escribir backend “limpio”: puertos, adaptadores, dominio aislado. Pero cada vez más el código no solo lo leen personas, también lo leen agentes de IA, que trabajan mejor cuando pueden cargar todo el contexto de una vez y pagan literalmente por cada token. ¿Y si lo óptimo para un humano y lo óptimo para una IA no coinciden?
Objetivo
Aislar una sola variable —cómo se reparte el código fuente— y comparar dos extremos con todo lo demás idéntico: arquitectura hexagonal + DDD frente a un único fichero, incluyendo el coste en tokens que supone cada enfoque para un agente de IA.
Alcance
La misma funcionalidad implementada dos veces: crear, listar, completar y borrar tareas, sobre /api/todos, con el mismo stack (Java 21, Spring Boot 3, Spring Data JPA) y los mismos 4 casos de uso. Ninguna versión añade ni quita nada respecto a la otra. Quedan fuera, a propósito, la capa de tests y la configuración de build, para no meter ruido en la comparación.
Diseño
Dos implementaciones y un explorador de código para navegarlas lado a lado:
- Hexagonal + DDD — 17 ficheros, 399 líneas, 5 niveles de directorios:
application(DTOs y servicios),domain(modelo, puertos in/out, excepciones) einfrastructure(adaptadores web y de persistencia). - Single-file — 1 fichero, 144 líneas, 1 nivel: toda la app en un sitio, pensada para que un agente de IA cargue el contexto completo de una sola vez.
La demo añade una comparación objetiva (ficheros, líneas, niveles) y, lo más interesante, el coste en tokens de leer cada versión con un LLM.
Decisiones técnicas
- Mismo stack y misma API en ambas para que la única variable sea la distribución del código.
- Sin tests ni build: reducen la señal que se quiere medir.
- La versión hexagonal aplica DDD “de libro” (puertos/adaptadores, entidad de dominio separada de la entidad JPA); la single-file colapsa todas esas capas en un archivo.
Implementación
Todo está en una demo autocontenida (HTML/CSS/JS, sin dependencias): árbol de ficheros de cada versión, visor de código y las métricas calculadas. Abre la demo para navegar ambos árboles y ver el coste en tokens:
Demo → /demos/compara-arq-hexagonal-vs-singlefile-todoapp/
Resultado
Para una funcionalidad idéntica, la versión hexagonal usa 17 ficheros y ~2,8× más líneas (399 vs 144) repartidas en 5 niveles de directorios. Ese reparto ayuda a un equipo a razonar por capas, pero para un agente de IA significa abrir muchos ficheros y gastar bastantes más tokens para reconstruir el mismo contexto que el single-file ofrece de golpe.
Limitaciones
Es una Todo App trivial (4 casos de uso): justo el escenario donde la hexagonal parece “sobreingeniería”. A medida que crece el dominio, la separación por capas empieza a pagar en mantenibilidad y pruebas, algo que esta PoC no mide. Tampoco evalúa el onboarding humano ni el tiempo de desarrollo de forma rigurosa.
Conclusiones
No hay ganador universal: depende de quién lee el código. Para un equipo y un dominio que va a crecer, hexagonal + DDD sigue mereciendo la pena. Para que un agente de IA cargue el contexto completo y trabaje barato en tokens, el single-file gana con claridad. El siguiente paso natural es repetir la comparación con un dominio más grande, donde el equilibrio probablemente se mueva.