Arquitectura Hexagonal Laravel

En este curso aprenderás arquitectura hexagonal en Laravel tal y como se definió: puertos y adaptadores, sin DDD de por medio. Casi todo el material que encontrarás mezcla los dos conceptos y presenta las capas de dominio, aplicación e infraestructura como si formaran parte del patrón. No lo son. Aquí construirás un gestor de tareas cuyo núcleo no conoce Laravel, y que podrías llevarte tal cual a un proyecto Symfony, a un Zend o a un script de PHP plano.

Puertos driving y puertos driven

Partimos de la nomenclatura original de Alistair Cockburn, no de la traducción habitual a "entrada y salida". Los puertos driving son lo que tu núcleo ofrece al exterior: CreateTask, CompleteTask, ListTasks y NotifyOverdue. Los puertos driven son lo que tu núcleo necesita del exterior: TaskStore, Clock y Notifier. Entender esta dirección es entender el patrón entero.

Un núcleo que no conoce el framework

Dentro de src/Core montarás los modelos (Task, ListedTask), los errores propios (CoreError, InvalidRequest, TaskAlreadyExists, TaskNotFound), los puertos y una capa de servicios que los implementa. Esos servicios trabajan únicamente contra abstracciones: no saben que existe Eloquent, ni el contenedor, ni una petición HTTP. Verás también por qué esa capa podría llamarse igual UseCase o Handler sin que cambie nada.

Adaptadores intercambiables de verdad

En src/Adapter escribirás varias implementaciones para el mismo puerto: almacenamiento en memoria, en archivo y con Eloquent, además de un reloj de sistema y un notificador. Todas cumplen el mismo contrato, así que cambiar de una a otra no toca ni una línea del núcleo. Y del lado driving, adaptadores por CLI y HTTP que consumen exactamente los mismos casos de uso.

La capa de wiring

La tercera pieza es src/Wiring, un service provider que decide qué adaptador se inyecta en cada puerto y que puedes conmutar con una variable de entorno. Es el único punto del proyecto donde el núcleo y Laravel se tocan, y ahí es donde la inversión de dependencias deja de ser una frase de manual y se vuelve algo que puedes ver funcionando.

El núcleo, ejecutándose fuera de Laravel

Para cerrar el círculo crearás un directorio bin/ y ejecutarás los mismos casos de uso con PHP plano, sin framework de ningún tipo. Si el núcleo responde igual, la portabilidad deja de ser una promesa y pasa a ser una demostración.

Tests de contrato

Escribirás un test de contrato: un trait con un método abstracto que cada test implementa indicando qué almacén usar, de forma que una sola batería de pruebas valida memoria, archivo y Eloquent por igual. Cuando añadas un adaptador nuevo no escribes tests nuevos, solo declaras cuál es.

• Experiencia sólida con Laravel. Se recomienda haber completado la Ruta Laravel 11 o tener conocimientos equivalentes.

• PHP moderno: interfaces, tipado estricto, propiedades readonly y promoción de constructores.

• Programación orientada a objetos e inyección de dependencias con el contenedor de servicios de Laravel.

• Conocer los principios SOLID, en especial la inversión de dependencias. Puedes repasarlos en este artículo.

• Manejo básico de PHPUnit para escribir y ejecutar tests.

• Conocimientos básicos de Git y terminal. Puedes ponerte al día con el curso de iniciación con GitHub.

• No necesitas saber nada de DDD. De hecho, en este curso no lo vas a usar.

Este curso está dirigido a cualquier desarrollador Laravel que quiera dar el salto. No hace falta que lleves diez años ni que hayas trabajado nunca con arquitecturas limpias: hace falta que sepas moverte con soltura por un proyecto Laravel y que tengas ganas de entender cómo se construye software que aguanta.

Es un curso avanzado, sí, pero avanzado no significa inaccesible. Vamos paso a paso, escribiendo el código juntos y explicando el porqué de cada decisión antes de tomarla. Si alguna vez has abierto un artículo sobre arquitectura hexagonal y lo has cerrado a los dos minutos, es justo el tipo de persona para la que está pensado esto.

Y conviene aclararlo: la arquitectura es lo que separa a un programador de un ingeniero de software. Es lo que se pregunta en las entrevistas para los puestos que mejor pagan, lo que te permite liderar un proyecto en lugar de limitarte a ejecutar tareas, y lo que hace que una aplicación siga siendo mantenible tres años después. Con la IA escribiendo cada vez más código, el valor se ha desplazado hacia quien sabe decidir: qué estructura tiene sentido, dónde poner cada límite y por qué. Eso no lo aprendes pidiéndoselo a un modelo, lo aprendes construyéndolo.

La suscripción incluye soporte a través del foro del curso.

Las dudas que se planteen en el foro del curso serán respondidas en un plazo máximo de 24 horas laborables.

Las dudas planteadas deben estar relacionadas con el contenido del curso y no con desarrollos personalizados que no estén relacionados con el curso.