Arquitectura Hexagonal Laravel

La arquitectura hexagonal o arquitectura de puertos y adaptadores nos ofrece separar la lógica de nuestra aplicación en 3 capas.

Infrastructure
Application
Domain

La idea es simple, alta cohesión y bajo acoplamiento.
Aunque a priori puede sonar complejo, realmente no lo es.

DDD

DDD no es una tecnología ni una metodología, este provee una estructura de prácticas y terminologías para tomar decisiones de diseño que enfoquen y aceleren el manejo de dominios complejos en los proyectos de software.

Dentro de DDD tenemos Layered Architectures o arquitectura por capas, y dentro de estas, la arquitectura hexagonal, que es la que vamos a estar cubriendo en este curso.

Capas de la arquitectura hexagonal

Infrastructure

Ofrece la capa superior de esta arquitectura y es la que nos permite tener contacto con el exterior, por ejemplo el uso de paquetes externos.
Entre otras cosas, en esta capa podemos tener controladores, rutas, migraciones y cualquier cosa necesaria.
A su vez, esta capa es la que se comunica de forma directa con la siguiente: Application.

Application

Ofrece la capa intermedia de esta arquitectura y es la que nos permite conectarnos al dominio.
Esta capa es la que representa los casos de uso de esta arquitectura, crear un curso, actualizar un curso etcétera.

Domain

La capa final y más sensible, aquí va la lógica de negocio de nuestra aplicación y para estar desacoplados del todo no debemos utilizar nada externo, todo debe haber sido construido por nosotros. Entre otros, aquí podemos tener Excepciones del negocio, ValueObjects e información de nuestro repositorio en caso de que aplique, lo cual es muy recomendado.

Directorios conocidos

BoundedContext

Se conoce como BoundedContext aquello que aúna en su conjunto ciertas partes de nuestro sistema que definen una lógica completa, Productos, Usuarios, Carritos podría pertenecer al BoundedContext Shop.

Shared

El uso de la carpeta Shared es muy útil para compartir recursos globales con los BoundedContexts.

Motivaciones de la arquitectura hexagonal

• Desacoplarnos del framework tanto como sea posible.

• Ser independientes de la UI.

• Ser independientes de la BD aplicando el patrón repositorio.

• Ser más tolerantes al cambio.

• Alta cohesión.

• Bajo acoplamiento.

• Facilitar los tests.

Intención de la arquitectura hexagonal

¿Te imaginas que tras desarrollar una aplicación viene tu superior y te dice que ahora tu aplicación además de ser utilizada a través de la interfaz, también debe ser utilizada a través de API y Consola?
Sin duda es posible, pero la forma en la que has desarrollado tu aplicación sólo sirve para trabajar con la UI y debes volver a picar mucho mucho código.
Para solucionar esto tenemos a nuestra disposición la arquitectura hexagonal, la cual nos permitirá fácilmente llevar a cabo este nuevo reto de forma sencilla, ágil y reutilizando lo ya hecho.

Uso de principios SOLID

En ingeniería de software, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) es un acrónimo mnemónico introducido por Robert C. Martin (Uncle Bob) a comienzos de la década del 2000 que representa cinco principios básicos de la programación orientada a objetos y el diseño.

Cuando estos principios se aplican en conjunto es más probable que un desarrollador cree un sistema que sea fácil de mantener y ampliar con el tiempo.

Los principios SOLID son guías que pueden ser aplicadas en el desarrollo de software para eliminar malos diseños provocando que el programador tenga que refactorizar el código fuente hasta que sea legible y extensible. Puede ser utilizado con el desarrollo guiado por pruebas, y forma parte de la estrategia global del desarrollo ágil de software y desarrollo adaptativo de software.

S: SRP

Principio de responsabilidad única (Single responsibility principle) La noción de que un objeto solo debería tener una única razón para cambiar.

O: OCP

Principio de abierto/cerrado (Open/closed principle)
La noción de que las "entidades de software deben estar abiertas para su extensión, pero cerradas para su modificación".

L: LSP

Principio de sustitución de Liskov (Liskov substitution principle)
La noción de que los "objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa".

I: ISP

Principio de segregación de la interfaz (Interface segregation principle)
La noción de que "muchas interfaces cliente específicas son mejores que una interfaz de propósito general".

D: DIP

Principio de inversión de la dependencia (Dependency inversion principle)
La noción de que se debe "depender de abstracciones, no depender de implementaciones".

Puedes ver un artículo completo con ejemplos de principios SOLID aquí.

Si estás interesado en aprender a aplicar arquitectura hexagonal en Laravel, no te puedes perder este curso.

• Experiencia en desarrollo web de 5 años o más.
• Experiencia sólida en Laravel.
• Muchas ganas de aprender.

Los planes de suscripción trimestral y anual incluyen soporte a través del foro del curso.
Si compras o has comprado el curso, también puedes hacer uso del 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.