Crónica de una evolución: De MVC a Arquitectura Hexagonal

Muchos desarrolladores dicen que usan MVC (Modelo-Vista-Controlador) porque es lo que pone en la carpeta de su framework, pero la realidad en las trincheras es muy distinta. Tras años de pelearme con código heredado, decidí que ya era hora de dejar de "sobrevivir" al software y empezar a diseñarlo.

Esta es la historia de cómo comencé a migrar mis diseños hacia la Arquitectura Hexagonal, pasando por una etapa intermedia necesaria.

El punto de partida: El Caos Ilustrado

En mi caso ha sido muy habitual trabajar con software heredado, así que me encontré con lo que muchos sufrís a diario:

• Consultas SQL en los controladores: Verificación de un dato con una consulta SQL repetida en cada controlador para verificar información. Los casos típicos: si un usuario está activo, tiene permisos, si un dato es accesible. Cuando por algún motivo se cambia el criterio, se crea inconsistencia que no siempre se descubre a tiempo.
• Consultas SQL en las Vistas: Código de base de datos mezclado con HTML. Un cambio en una columna rompía la interfaz.
• Controladores Obesos: Lógica de negocio, validaciones y acceso a datos, todo en una función de 500 líneas.
• La Tiranía del Copy-Paste: Duplicar controladores y modelos enteros para crear funciones parecidas en lugar de usar herencia. Un error corregido en un sitio seguía vivo en otros cinco archivos idénticos.

Fase 1: El nacimiento del "MVSC" (Servicios al rescate)

Mi primera decisión no fue ir a una arquitectura de libro, fue poner orden por salud mental. Introduje la "S" de Servicio en el esquema:

1. Modelos y controladores a dieta: Vacié los modelos y controladores. Dejaron de ser "sabelotodos" para ser entidades ligeras.
2. Servicios Centralizados: Extraje la lógica de negocio de los controladores y modelos y la moví a Servicios.
3. Adiós al SQL desparramado: El SQL se quedó confinado. Si había que calcular algo o consultar la base de datos, se hacía en el Servicio, no en la Vista.
4. Barra de depuración: Utilicé la barra de depuración para que me avisara de los incumplimentos de los patrones.

Resultado: El código empezó a ser reutilizable y la herencia empezó a tener sentido. Pero seguíamos "casados" con el framework.

Fase 2: El Salto a la Arquitectura Hexagonal

Con los servicios ya limpios, el paso final si se estima necesario, es blindar el núcleo. El principio es sagrado: el corazón de tu aplicación no debe saber nada del mundo exterior.

En Alxarafe Framework, ahora divido todo en tres capas estancas:

• Dominio (src/Domain): El núcleo sagrado. Reglas de negocio en PHP puro. No sabe si existe MySQL o una API. Es donde viven las entidades y las interfaces.
• Aplicación (src/Application): Aquí viven los "Casos de Uso". Son los antiguos servicios evolucionados que orquestan qué debe pasar, pero sin ensuciarse con detalles técnicos.
• Infraestructura (src/Infrastructure): Aquí es donde viven los "cables". El SQL (y solo aquí), los adaptadores de IA, el Framework y la interfaz de usuario.

¿Por qué este viaje es vital para la IA?

Si le pides a una IA que te ayude en un código lleno de archivos duplicados y SQL en las vistas, el resultado será basura.

En cambio, con esta estructura, la IA se convierte en un multiplicador. He diseñado los Asistentes de IA como simples adaptadores en la capa de Infraestructura. Si mañana sale un modelo mejor, lo conecto al "puerto" correspondiente y mi lógica de negocio no se entera. He construido un software que no teme al futuro porque ha dejado de estar encadenado a las malas prácticas del pasado.

Resumiendo: La arquitectura no es un dogma: es una herramienta para que el software sobreviva al tiempo.