Arquitectura avanzada en Laravel con DDD para proyectos escalables

Bienvenid@ al curso de Arquitectura avanzada en Laravel con DDD. Lo que cubriremos en este curso son temas avanzados sobre arquitectura en Laravel para el desarrollo de aplicaciones orientadas a entornos profesionales haciendo uso de las mejores prácticas de programación.

La meta de este curso es ofrecerte una nueva y avanzada forma de escribir aplicaciones Laravel para tus futuros proyectos, la cual será válida para pequeños y grandes proyectos.

Para conseguir los mejores resultados aplicando DDD en proyectos Laravel te recomiendo revisar el curso de Arquitectura Hexagonal, ahí cubrimos temas que se pueden llevar a cabo en este proyecto para mejorar la aplicación de DDD como por ejemplo los ValueObjects.

Sin dependencias externas, o las mínimas

Una de las principales premisas al momento de desarrollar aplicaciones escalables y fáciles de mantener es intentar utilizar el mínimo de dependencias externas, con dependencias externas me refiero a paquetes instalados con composer.

En este curso las dependencias utilizadas serán Laravel Excel y el Stack Inertia. Dicho esto, todo lo que vamos a hacer con Inertia es perfectamente válido para otras formas de desarrollo dentro de Laravel.

El motivo de utilizar el mínimo de dependencias es que las posteriores actualizaciones pueden ser muy dolorosas, utilizando el mínimo de recursos externos, podremos actualizar fácilmente sabiendo que todo seguirá funcionando.

DDD

El diseño guiado por el dominio, en inglés: domain-driven design, es un enfoque para el desarrollo de software con necesidades complejas mediante una profunda conexión entre la implementación y los conceptos del modelo y núcleo del negocio. La idea es sencilla, centrarnos de forma completa en la lógica de negocio.

Cambiamos la forma de escribir código en Laravel

En Cursosdesarrolloweb hemos desarrollado muchos cursos, en todos ellos siempre haciendo uso de buenas prácticas. En varios de los cursos de la plataforma hemos aplicado el patrón repositorio, que no es más que una clase que implementa toda la lógica de Eloquent (por defecto en Laravel) para cada modelo desacoplando la lógica de base de datos de los controladores.

De esta forma podemos tener controladores limpios y pasar toda la lógica de los modelos a clases independientes. Este enfoque está bien, pero cuando trabajas en grandes proyectos, algo no termina de funcionar. El problema viene cuando desde un repositorio que trabaja por ejemplo con un modelo Post debemos acceder a diferentes modelos, en ese momento te das cuenta de que si bien es posible hacerlo, algo no termina de estar bien.

Controladores sencillos

Una de las cosas que personalmente más me gusta es tener controladores sencillos, ¡ojo! esto no significa crear abstracciones absurdas hasta el punto de no saber qué hace tu propio controlador. He visto tutoriales y cursos de refactorización en Laravel que haciendo uso de observables, eventos y más características de Laravel, un desarrollador que se incorpore al equipo de desarrollo no sabría qué hace dicho controlador, nunca hagas algo similar.

Modelos de vista

Los modelos de vista son algo que desde que lo aprendí no he dejado de utilizarlo. Se trata de tener clases que ofrezcan a través de cada uno de sus métodos públicos propiedades para el cliente, por el cliente me refiero a las plantillas, Vue, React o Blade en este caso.

La clave de los modelos de vista es que podemos nutrir de los datos necesarios a cada vista desde un único punto fácil de entender, testeable y con código limpio.

Acciones

Las acciones son cosas que suceden en nuestra aplicación, crear un post, actualizar un post, exportar datos a un excel etcétera. Las acciones en nuestro caso, ya que estaremos trabajando con DDD, estarán ubicadas en cada contexto, Blog, Tienda, Envíos etcétera. En el caso del blog, tendremos varias acciones, CreatePost, UpdatePost, ExportToExcel. Lo mejor de las acciones sin duda es que sólo por ver los archivos del directorio Actions de un contexto podemos saber qué capacidades tiene dicho contexto.

Filtros

Otro de los puntales de nuestro desarrollo serán los filtros, gracias al patrón de diseño Pipeline podremos escribir filtros basados en una abstracción que nos permitan filtrar todos los datos, por ejemplo de nuestros listados.

La idea será utilizar el passable del Pipeline a través de una serie de Filtros para que nuestras consultas queden bien organizadas y en archivos independientes.

El concepto Shared en DDD

Shared es todo aquello que deba ser compartido entre diferentes contextos de tu aplicación, por ejemplo, el modelo User sería un modelo dentro de la capa Shared. Las abstracciones también pueden pertenecer a Shared si aplican a diferentes contextos.

Simplemente debemos poner en Shared todo aquello que no pertenezca a ningún contexto y que pueda ser utilizado en varios contextos.

Si estás interesado en aprender a aplicar DDD en Laravel para escribir código de manera profesional y sorprender a tu entorno de trabajo, no te puedes perder este curso.