Видео

@@aldairmanzanosanchez8538 hola! Muchas gracias 🙌 Claro que si, vamos con el ejemplo: Aquí estamos hablando de una situación en la que se requiere que en una vista (por ejemplo) necesitemos ver datos de un usuario al igual que su rol, pero a nivel de código y base de datos estos son cada uno un módulo distinto, ¿que hacemos? Fácil. Le damos al front lo que quiere. Si estamos accediendo a esa información desde el módulo de User pero en el objeto User necesitamos información del Role, podemos entonces agregar las propiedades que necesitemos (roleId, roleName, o incluso una propiedad role que dentro de sí tenga un objeto de tipo Role). Ahora, ¿dónde se hace esto? En dos lugares: 1. Modelado de dominio, aquí agregaremos las propiedades que nos hagan falta a nuestro User, y no hay tanto problema porque gestiones específicas de Role las seguimos llevando en ese módulo y aquí User solo se relaciona con Role para consulta 2. Capa de infraestructura (ver video Cap. 3), dado que ahora para instanciar un objeto User se necesitará nueva información, debemos hacer las relaciones necesarias a nivel de base de datos en el repositorio para poder cumplir con los datos que pedimos en nuestro modelado de dominio Avísame si tienes dudas, un saludo 🙌

Hola @mvrcoag, muchas gracias por tu respuesta. Después de analizar tu sugerencia, entiendo que propones convertir el rol en un Value Object dentro del usuario, lo que facilitaría la gestión. Además, como mencionas, sería la capa de infraestructura la encargada de devolverme esos datos. Esto funciona bien en el caso en que solo se requiera lectura, pero, ¿Qué ocurre si también necesitamos escritura y lectura? Por lo que entiendo de tu código, estás aplicando DDD (Diseño Dirigido por el Dominio), lo que nos permite modularizar el código siguiendo ese patrón. Ahora, supongamos que tienes una orden de pago que, al crearse, también debe generar un pago simultáneamente. Dado que estamos utilizando un enfoque DDD, deberíamos tener dos agregados: uno para Orders y otro para Payments. En este caso, ¿Cómo modelarías las entidades para reflejar esta relación y cómo gestionarías la obtención de la orden junto con sus pagos asociados?, Además ¿Cómo garantizarías que ambas acciones sean transaccionales? Finalmente, ¿Dónde aplicarías esta relación, considerando que mencionaste que la idea es evitar dependencias entre los casos de uso? ¿Quedaría esta relación también en la capa de infraestructura?

@@juanjzb me alegra que te haya servido! Un saludo Juan 🙌

@@enzofrias1367 muchas gracias! 🙌 Aquí como en todo, depende. Si será una aplicación pequeña-mediana en la que como máximo solo 3 personas estarán trabajando, de pronto los value objets no nos compensan, para este ejemplo mejor optaría por validaciones directas usando librerías como Zod pero siempre encapsulandolas en archivos pertenecientes a capas de dominio

​@@mvrcoagbuenismo! Muchas gracias!

Hola! Muchas gracias Yo también comencé con PHP, es un gran lenguaje que sin duda permite hacer cosas increíbles, ¿Lo usas con o sin framework? Me da gusto que te encuentres probando, ¿Alguna tecnología que te gustaría que exploráramos en el canal? Un saludo!

Mucho éxito en tu trayectoria como desarrollador, para mi es un placer ayudar a otros con mi experiencia a lo largo de los años. Un saludo desde México!

Hola Juan, ¿Cómo estás? Verás, la sintaxis que usamos en esa línea se llama "parameter properties", que permite definir y asignar automáticamente propiedades de clase en el constructor de forma concisa Si no quisieras establecer el private en el mismo constructor, lo que podrías hacer es declarar una propiedad por separado y luego asignarla en el constructor, que funciona, pero personalmente me parece que se escribe más código Ahora, si tu duda esta en la palabra clave "private", se utiliza para definir el nivel de acceso de una propiedad o método dentro de una clase. Cuando declaras una propiedad o un método como private, significa que solo puede ser accedido desde dentro de la misma clase en la que fue definido, y no desde fuera de la clase o desde otras clases que hereden de ella Hazme saber si te quedan dudas, ¡Un saludo!

Hey, muchas gracias! Saludos desde México

¡Que bueno que te haya gustado! ¿Algún tema en especifico que te gustaría que exploremos? Un saludo

¡Hola Fer! Muchas gracias En mi caso uso Github Copilot, te dejo el enlace por si te interesa: github.com/features/copilot ¡Un saludo!

¡Hola Alejandro! Es tan estricto como tu aplicación lo requiera. Se considera una buena practica seguir el principio de "responsabilidad única". Bajo esta premisa un método debería hacer solo una cosa y no más. Continuando con el ejemplo, si un método guarda en la base de datos y además devuelve el resultado tendría dos responsabilidades, y si bien podemos dejarlo pasar aquí ya hay algo que nos puede decir que las cosas no están del todo bien, ya sea el flujo de nuestra aplicación o la arquitectura de la misma. Hay casos donde por ejemplo requieres el ID del recurso que se acaba de crear y es por esto que necesitas que el método devuelva el objeto una vez lo crea. Para lo anterior una buena practica es no delegar a la base de datos la responsabilidad de generar identificadores sino generar el ID desde nuestro código, con este cambio la necesidad de devolver el recurso recién creado carece de sentido debido a que nosotros sabemos con qué datos se crea ya que le pasamos la información completa, además de que tenemos mucho más control sobre nuestro aplicativo al no depender de terceros (en este caso la base de datos para generación de IDs). Claro que todo lo anterior funciona solo bajo el "depende", pero siempre es bueno conocer la mayor cantidad posible de puntos de vista para que llegado el momento tomemos la mejor decisión. ¡Un saludo!

¡Hola! Para el caso de validaciones podríamos usarlas directamente en dominio siempre que asumamos la responsabilidad de no cambiabilidad a lo largo del tiempo, es decir, asumir que Zod en este caso será el estándar de validación a lo largo de todo nuestro proyecto y tratarlo como un paquete interno del lenguaje. Al final la opción del repositorio (o de cualquier forma de implementación de interfaces de dominio) es válida, pero entendemos que puede ser mucho código y abstracciones para algo tan sencillo como validar datos. Aquí habría que poner en una balanza si realmente necesitamos esa separación de conceptos tan estricta o si bien podemos asumir la responsabilidad de estandarización de Zod y usarlo directamemte en nuestros value objects. Al final, como casi todos los casos, dependerá del contexto del proyecto, al final la arquitectura hexagonal más que ser una estricta guía es una serie de patrones que se adaptarán más o menos a nuestro contexto, lo importante es conocer todas nuestras herramientas y saber para qué casos resulta mejor usarlas. Si tienes dudas quedo pendiente, ¡Un saludo!

@@mvrcoag Todo claro, muchas gracias. Resumiendo deberia usar ZOD como middleware para validar si los TIPOS DE DATOS y alguna que otra regex cumplen con lo que necesita mi controllador. Y la validacion de los value object es solo para hacer validaciones a la entidad de nuestra logica de negocio, como por ejemplo un descuento en una prenda de vestir, una divisa local, igv, etc.

Hola Abel! Justo ese es uno de los puntos más fuertes de la mayoría de arquitecturas limpias, y es que puedes cambiar las tecnologías de terceros (como el ORM) sin afectar gran parte de tu aplicación, sino solo donde este se instancia ya que las interfaces nos funcionan como intermediarios. Es decir, para este caso solo tendrías que crear tus nuevas implementaciones de los repositorios para el nuevo ORM (tal como se hizo con TypeORM) e instanciarlo en donde quieras consumirlo, de esta forma ni la capa de aplicación y mucho menos la de dominio se verán afectadas. Si tienes dudas sigo pendiente, un saludo! 👋

¡Hola! En cuanto a tu primer punto me llama la atención y coincido en que el binding se vuelve verboso, aquí sacrificamos conveniencia por separación de conceptos al definir estrictamente qué repositorio usará cada caso de uso para de esta forma no llevarnos la directiva "@injectable" de Nest JS (infrastructure) a capas de application o de domain, ¿De qué forma lo solucionarías tú sin contaminar capas internas con código o dependencias de infraestructura? Te leo Continuando, totalmente de acuerdo, Nest JS maneja la inyección de dependencias de tal forma que se vuelve difícil hacer una implementación sin acoplarnos directamente al framework, cosa que en arquitecturas limpias nos interesa evitar. En cuanto al ejemplo del FakeUserRepository, al ser esta una implementación de "UserRepository" yo no lo pondría en domain sino en infrastructure, y no lo pondría en el código "src" sino en el código de "tests", esto para tener bien separados los conceptos de código de producción y código de testing. Un saludo!

@@mvrcoag En los proyectos donde aplico hexagonal y DDD intento buscar un equilibrio entre codigo que es 100% desacoplable y herramientas del framework donde puedo asumir un pequeño acople para no perder facilidad en el manejo del mismo. Para este caso yo me acoplaría al @injectable o intentaría hacer un helper como ya dije en shared. Por la parte del @inject en los constructores utilizaría clases abstractas que si se pueden instanciar y el framework puede inyectar sin necesidad de un Symbol. Por la parte del FakeUserRepository, aun que sea un repo de test esta claro que no cambiara segun mi implementacion real, es decir, si mañana cambio la implementacion de produccion el fake del teste no deberia tener ningun cambio

Hola Alejandro, últimamente he estado algo ocupado con temas del trabajo, sin embargo Docker es una tecnología bastante interesante y que se puede aprovechar muy bien en flujos de trabajo modernos y claro que me interesa la idea de hacer un video al respecto! Aún así si tienes dudas especificas siempre puedes contactar conmigo por mis redes sociales, casi siempre suelo estar más activo por LinkedIn por lo que si necesitas algo con gusto trataré de ayudarte. ¡Un saludo y pronto volverán los videos!

@@mvrcoag gracias bro, por el apoyo, es que no hay manera que yo logre entender el kubernetes, y entonces como te entiendo tan bien, queria ver si lo entiendo, solo eso, gracias por los videos!

Hola! Es correcto, para proyectos donde no solo existe un módulo (la mayoría) es correcto optar por centralizar las funciones o clases compartidas como esta que comentas. La solución que personalmente uso en mis proyectos y equipos es generar el archivo en la carpeta /lib/Shared/domain/Id. De esta forma mi código sigue dentro de mi carpeta principal "lib", y a partir de "Shared" cualquier otro módulo puede acceder a esas utilidades globales. ¡Un saludo!

Me alegra mucho que te haya funcionado! Saludos desde México 👋

Hola Alonso! Bienvenido de vuelta al software! Suena bastante interesante el proyecto, especialmente porque nunca he tocado temas de Wordpress o parecidos, me sería muy interesante saber cómo aplicas estos conceptos a esas tecnologías. Muy interesante tu análisis para el proyecto que llevas, te deseo mucho éxito! Un saludo 👋

Hola! Qué bueno que te gustó, y espero que te funcione de maravilla en este y los próximos proyectos que desarrolles, mucho éxito! Saludos! 👋

Muchas gracias! Saludos desde México 👋

Muchas gracias! Un saludo 👋

Hola Santiago! La idea del value object es primero que funcione como entidad de modelado de nuestro dominio y de esta forma lograr que sea más expresivo, y segundo que funcione como validador de nuestra aplicación y así no depender directamente de validadores de terceros. Ahora, perfectamente podemos usar librerías en nuestros value objects para el tema de validación *siembre que asumamos la responsabilidad de mantenimiento a lo largo del tiempo de estas librerías*. Es decir, podrías tener un value object que se apoye en Zod para las validaciones, pero tu aplicación ni cuenta se dará de que usas Zod, solo conocerá al value object. Saludos! 👋

@@mvrcoag gracias me puse a leer u poco más y tienes razón el correcto es q el domain no se acople a librerías externas por q llega a tener dependencia

Hola Santiago! Es una practica para tener todo el código de nuestra lógica de negocio ahí, podrías tener otro nombre como "modules" o "sections", personalmente me gusta llamarlo "lib". Otro beneficio que nos aporta es que al tener todo contenido en una sola carpeta si el día de mañana queremos reutilizar nuestros módulos en un nuevo proyecto es tan fácil como copiar, pegar e ir llamando los módulos donde los necesitemos. Un saludo 👋

Hola! Sí, siempre que asumamos la responsabilidad de que Zod no cambiará en nuestro modulo es valido usarlo como agente de validaciones para nuestro dominio. Un saludo! 👋

🙌

Me alegra que te haya servido Jesus! Un saludo 👋

Qué bueno que te gustó! Un saludo 👋

¡Muchas gracias! Un saludo

Hola! Justamente vertical slicing y screaming architecture son dos técnicas que mejoran aún más la claridad del software, gracias por tu aporte!

Hola! Lo que propones es un muy buen enfoque, sin embargo hay ocasiones en las que requerimos de datos primitivos que JSON no puede manejar (como el objeto Date) para trabajarlos dentro del mismo flujo antes de enviar la respuesta al cliente. Si bien esto no aplica a todos los casos, estoy de acuerdo en que mientras más sencillo sea el software mejor, y toJSON lo hace bastante bien. ¡Muchas gracias por tu aporte!

¡Muchas gracias Luciano! Excelente idea, tal vez podamos hacer un video dedicado a errores y cómo aprovecharlos, ¡Gracias por el aporte!

¡Hola! Lo que intentas de hacer es tarea del repositorio, ya que si bien dentro de dominio no debería haber contaminación con otros dominios de otros módulos, el repositorio sí puede interactuar directamente con la base de datos y con las tablas que necesite, y es este el que se encargaría de hacer las relaciones necesarias ya sea para lectura o escritura de datos. Aquí el dominio solo tendría que tener los datos necesarios tanto para lectura o escritura, y en caso de que no pudieran ser iguales (por ejemplo, porque para leer un usuario no necesitas su roleId pero para crearlo sí) entonces podríamos tener dos clases, una de read model (UserReadModel) y otra de write model (UserWriteModel) y que estás se usen de acuerdo a las necesidades. Si tienes dudas quedo pendiente, ¡Un saludo!

Es un placer! 🙌 Qué bueno que te gustó! Saludos 👋

Podrías agregarlo a tu modelado de dominio y a partir de ahí menejarlo a lo largo de toda la aplicación. El hecho de que sea un serial o autoincrementable carece de importancia a nivel de modelado ya que eso lo decidirás en el dominio para terminar afectando la base de datos, realmente puedes usar cualquiera de los dos! 🙌 En el canal tenemos varios videos llevando estos ejemplos a casos reales utilizando distintas tecnologías, aún así si quedan dudas házmelo saber! Un saludo! 👋

@@emanuelpalacio-q3l hola! 🙌 Tienes toda la razón, y comparto tu opinión, la arquitectura hexagonal no es para todos los proyectos. ¿Donde sí lo aplicaría? Por ejemplo, en proyectos grandes donde los equipos sean mayores a 2 personas y el proyecto tenga proyección a futuro. De esta forma aprovechamos todas las ventajas de la arquitectura hexagonal y la complejidad ya nos compensa. Es cierto que para proyectos menos complejos la arquitectura hexagonal puede traer más problemas que beneficios, y aquí optaría por frameworks con soluciones out-of-the-box como Nest que ya tiene sus opiniones respecto a como hacer y estructurar el proyecto. Mi intención es compartir los conocimientos y experiencia que he adquirido al trabajar en distintos tipos de proyectos, agradezco mucho tu punto de vista! Un saludo 👋

@@sanchezcarlos1986 Muchas gracias Carlos! 🙌 Me alegra que te haya gustado! Saludos 👋

@@andres-kj9hg ¡Muchas gracias! 🙌 En cuanto al ORM es sencillo, lo puedes aislar a su propia carpeta en la capa de infraestructura. Por ejemplo, si quieres usar TypeORM en un módulo de "User" podrías crear una carpeta en User/infrastructure/TypeOrm y aquí por ejemplo archivos como TypeOrmUserRepository y TypeOrmUserEntity. Esto variará en función del ORM que uses, aunque aquí ya que se trata de infraestructura tenemos más flexibilidad a la hora de definir como creamos, nombramos, y relacionamos los archivos entre sí. En el canal hay un vídeo de Nest JS + TypeORM, tal vez ese ejemplo te pueda ayudar, y si tienes más dudas házmelo saber! Un saludo 👋

¡Tú idea me parece excelente, suena como un video largo sin embargo la idea me emociona mucho! Muchas gracias por tu aporte, un saludo

@@mvrcoag estaría genial 🙌

Qué gran idea! 🙌 En el canal ya tenemos un vídeo de Nest JS con Hexagonal, pero la parte de microservicios me parece bastante interesante para cubrirla en un vídeo, un saludo! 👋

@@mvrcoag, definitivamente broth. Ya que la comunicacion entre los distintos modulos y la configuracion varia un poco.

@@AndresSuarez-zd3oe muchas gracias Andrés! 🙌 Es un placer compartir mis experiencias y conocimientos con las personas, un saludo! 👋

@@AndresSuarez-zd3oe muchas gracias! 🙌 Que bueno que te aportó, un saludo! 👋

@@eduardovielma7205 muchas gracias! 🙌 Un saludo! 👋

@@Deus-lo-Vuilt muchísimas gracias! 🙌 Un saludo! 👋

Hola David, me alegra que te haya gustado! 🙌 La idea me gusta, microservicios funciona de maravilla con la arquitectura hexagonal, y qué mejor que tener un ambiente local tan organizado como Docker lo permite. Muchas gracias por tu aporte y sugerencia, un saludo! 👋

Hola Daniel! 🙌 Qué gusto que te haya aportado. En cuanto a tu duda, sí, es totalmente posible, aunque hay que tener cuidado en abusar de la carpeta "Shared" ya que podría volverse la carpeta donde terminemos metiendo todo y entonces perdería sentido la división de módulos que justamente propone la arquitectura hexagonal. Si tienes más dudas quedo pendiente, un saludo! 👋

Es un placer Alejandro! 🙌

Me parece muy buena idea, creo que podría complementar muy bien los videos que existen en el canal! 🙌 Muchas gracias por el aporte David, un saludo 👋