Mejora tu código aplicando Clean Architecture
Vložit
- čas přidán 21. 09. 2022
- Las Clean Arquitectures y en concreto la Arquitectura Hexagonal nos pueden ayudar a hacer nuestro código más mantenible, testable y escalable. Aprende a aplicarlo y validarlo en tu código gracias al plugin de ESLint que hemos desarrollado: www.npmjs.com/package/eslint-...
Todo esto y más lo vemos en detalle en el curso de Linting en JavaScript y TypeScript, para exprimir al máximo ESLint y llevar tu código al siguiente nivel 👉 pro.codely.com/library/lintin...
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🌶 Twitter Núria: / nuria_codes
├ 💂🏼 Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🟦 Facebook: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
¿Utilizas una Clean Architecture? 🤔
Aquí el curso 🙂👉 bit.ly/linting-js
Aquí el plugin para que le des una estrellita ⭐👉 github.com/CodelyTV/eslint-plugin-hexagonal-architecture
Estaría super que realizaran un ejemplo en frontend (React) de como se aplicaria el patron repoositorio por ejemplo con esta arquitectura
@CodelyTv Por favor tenerlo en cuenta, con ejemplos practicos y sencillos se entiende mejor el tema
En un repositorio vos podés escribir y leer data. En "backend" haces implementaciónes de bases de datos. Por ejemplo MYSQL, Firestore. Para "frontend" también podes hacer algo similar pero con localstorage, o alguna API que por detrás consulte a la DB.
Sr.@@jefjef418 Excelente aporte
El mejor video de este canal creo yo... Facil y AL PUNTO!
Gran vídeo! Sería genial ver un ejemplo completo, analizando cada capa y ver cómo se une con la UI! :)
Excelente contenido, y con lo del plugin la sacaron del estadio, mil gracias.
Excelente video ya lo había visto hace tiempo pero hoy lo volví a ver
Love it, genial, el plugin excepcional.
Que buena codely! buen video!
Amé su video!
Buenísimo chicos. Unos cracks.❤
Excelente video se les felicita!!! 😀
Woooowwwwww que super mega herramienta 👏👏👏👏
Este vídeo tendría muchísimas más visitas si se añade información relevante al ESLint en el título. (seguramente)
OLE!! OLE!! y OLE!! jejejejej. Que apañaos que sois ^^. Seguir así! muchísimos ánimos!
Hola Nuria y Rafa, Primero felicitaros por el plugin y por el video que seguro le aportará muchísimo a mucho desarrolladores. Por otra parte seguro que lo sabeis pero creo que sería interesante para el resto que se comentara que las distribuciones de carpetas tienen nombre, Vertical Slicing(Cuando agrupamos cohesivamente por caso de uso o modulo) y Horizontal Slicing (Cuando agrupamos por el rol del elemento software Controlador, Vista, Modelo, Repositorio o lo que sea), al final en el ejemplo que ponen terminan en un mix que es como yo lo uso, vertical slicing y dentro de cada modulo horizontal slicing. Un saludo!!
Pedazo de video, graciaas
Después de tanto buscar acabo de entender cuan potente es la arquitectura hexagonal junto con la vertical slice gracias a ustedes. Muchas gracias.
Excelente explicación!!!
Gracias por el contenido!
Superrr pulgin!! lo voy a probar :)
wao... plugin que aporta valor !! nunca mejor dicho
Dios mio, al fin ejemplos para el frontend, mayormente todo esta enfocado a Backend, espero sigan sacando temas orientados a Frontend. Gracias por el aporte.
Buen video buen explicado
It’s totally worth learning new skills cause then you get excited and confident to create
Excelente!
Muy interesante estos videos
Muy brutal
He visto a dios, y no hablo por el vídeo en si que por conocimiento y experiencia puedo darles la razón, sino por lo de ESLint. Eso me da ideas de crear extensiones para visual studio que ayuden a la correcta aplicación de los conceptos clave de la programación.
Despacio franchute, esto es oro.
Muy buen video
Amé el resumen y la herramienta. Creo que igual la fusión o explicación al detalle de hexagonal en Frontend sería algo genial así sea en los cursos de CodelyTV
Estoy trabajando actualmente para una startup, definiendo todo tipo de lineamientos técnicos y el valor que me aportan para poder avanzar es increíble. Desde Argentina, MUCHISIMAS GRACIAS CODELYTV!
Muchas gracias por tu mensaje!!
wowwwwwwwwwwww superrrrrrrrrr!!!
Guys it really works, I checked
Lo voy a usar en mi proyecto de NextJS a ver cómo se ve
Súper claro y recomendable el vídeo! Una pregunta: Conocéis algún linter como el que habláis aplicado a PHP?
En una arquitectura hexagonal tengo entendido que se una un cocepto de drivers, drivens, adapters, y ports pero aquí confunden conceptos. Si estyo mal me corrigen. Pero gracias por el contenido
Genial el video, sería bueno que hagan un ejemplo para frontend de manera general para uno saber aplicarlo al framework que usa, busco mucho arquitectura del frontend pero no encuentro mucha info sobre esto, un saludo al equipo, gracias por el contenido. ❤
Me recuerda a ArchUnit para java. Muy interesante.
Muchas gracias por la explicación, tendrían el repo del ejemplo que han creado que tiene el uso de lint.
Gracias por el contenido! Tienen algo similar pero para aplicarlo en un proyecto PHP?
Una pregunta, cuando un puerto externo ya sea un consumo de authenticacion o login que devuelve tókens y cosas así. El caso de uso quedaría con la respuesta asociada a ese token ?
entonces se recomienda utilizar primero fetch antes que axios?
Sería muy bueno ver un ejemplo de esta arquitectura aplicada a un proceso de datos, tipo ETL. Muchas gracias por los vídeos 😊 Son de mucho valor
Ufff ETL...difícil de explicar bien, porque en los casos ejemplo (una tabla maestra y un par de tablas anidadas) es muy sencillo, escalable y flexible... pero cuando llegas a casos reales, las cosas son más complicadas y aunque en esencia es lo mismo, el código se complica para manejar casos especiales y esos casos son diferentes según el problema que tengas...
Es decir, si tomas como ejemplo un caso complicado, la solución está muy ligada a ese problema y es probable que no la puedas usar siempre... por eso digo que ETL es muy difícil de explicar bien.
Trabajé en un proyecto ETL donde la tabla maestra dependía no sólo de otras tablas, sino de otros sistemas como SAP , apps privadas, archivos, datos en memoria... y no era una única tabla maestra, era un modelo completo de al menos 100 tablas...
Ahí aprendí por las malas que una solucion general para ETL no existe, siempre hay casos especiales que "dañan" el modelo general (lo que aprendes en un curso), y esos casos no sólo están influenciados por la complejidad técnica, sino también por lo que el cliente quiere, y si haces una app que va a ser usada por diferentes clientes y cada uno quiere importar cosas diferentes, con archivos y formatos diferentes, y filtrar/transformar los datos de manera diferente, todo se convierte en un desafío de la ingeniería... y manejar eso en un video/clase/curso es imposible...
Y la verdad es que se aprende más con la experiencia que con un curso ;) claro, los estudios son necesarios para tener más herramientas a la hora de solucionar problemas de verdad difíciles
Un ejemplo básico y fácil de ETL es como Elasticsearch extrae datos de una BD (MySql, MSSQL...), los transforma en Json y los indexa en su base de datos...
Todo funciona a pedir de boca, defines los scripts de extracción, simples selects, y como esos "Records" se transforman en Json, y donde esos Json son guardados en Elasticsearch... simple
Pero tuve proyectos donde eso no sirvió porque los datos de la BD no eran suficientes, había que enriquecerlos con sistemas remotos, cosas en las que la gente de Elasticsearch no pensó, ni programó...
el caso general (los simples scripts) no sirve y hay que escribirse un ETL completo desde cero para ese cliente...
en esos casos hay que inventarse una estructura básica y genérica que es la que trabaja los datos al final... digamos XML... tu algoritmo consume los datos desde ese XML definido por ti y haces con ellos lo que quieras...
si hay un cliente con lógica especial, entonces escribes un programa que toma esos datos de entrada en el formato que sea y los transforma en TU XML...
esa es la forma más elegante de mantener tu código limpio... no tiene buen performance porque los datos tienen que ser transformados hacia XML, y de XML hacia tu modelo, pero es demasiado flexible
Si lo haces bien, puedes tener un único algoritmo que importa datos en tu DB y puedes cambiar la fuente de datos on-the-fly... puedes importar datos de SAP, y con el mismo algoritmo puedes cambiar a importarlos desde un archivo, o tu misma BD
Échale un ojo a Mirth
Hola,gracias por el video,donde puedo encontrar un ejemplo con vertical slice? Necesito pasar un proyecto a hexagonal, gracias
Hola crack, tengo una duda y es algo que no me quedo muy claro usando el plugin, si tengo varios caso de uso pero en cada caso de uso estoy usando logger por ejemplo como hago para usarlo en todos esos casos de uso y que no se me repita por ejemplo la clase que cree usando logger
All of my computers got the softwares here. I first install them on virtual environnt to make sure they're not malware. So I can assure
Hola! Gracias por el video, tengo un par de dudas. Por qué dicen que están usando arquitectura hexagonal si no están haciendo uso de adaptadores y puertos ? Parece más Onion o Clean Arquitecture. Lo otro, por qué pueden haber tantas entidades dentro del proyecto? es un monolito?.
Si pienso en un MicroServicio debería tener 1 y probablemente el auth. O puede ser por ejemplo que este ms se integra y hace llamadas a otros ms como de product, course, student, etc.?
Muchas gracias.
Si es que lo entiendi bien... Repository podria ser un siguiente nivel de "capa de abastraccion" con respecto a los DAO, donde los metodos de repository no representan las operaciones basicas de un CRUD, sino que esta mas orientado a acciones puntuales necesarias en el negocio, pero que al momento de obtener la informacion, podria usar internamente DAOs. Es correcto?
🔥🔥🔥🔥🔥
Es más lo que mostráis en el 7:02 que es la buena forma es en verdad el paso previo a pasar a una arquitectura de microservicios con lo cual dabuten.
Thanks
Buenisimo el resumen Rafa y Nuria, pero tengo una pregunta, en el modelo de organización que proponen uniendo el concepto de screaming architecture con las carpetas por agregado de dominio, como se resolvería la necesidad de implementar casos de uso donde se requiera la intervención de varios agregados, como aplicarían las reglas de dependencia allí?
Hola Ernesto, buenísima pregunta, yo tambien me la hice en su momento y la solución que encontré fue creando un módulo shared donde a través de un index.ts exporto los agregados que se puedan usar en otros módulos, digamos que un caso de uso que necesita hacer uso de un agregado que pertenece a otro módulo solo lo debería poder importar desde el módulo shared. Evidentemente es una regla que te creas como diseño de tu arquitectura. En caso de usar monorepos existen reglas que se pueden definir donde se especifica que tipo de modulo puede importar elementos del dominio de que otros módulos, en esa regla yo especifico que un módulo estandar(todos menos el shared) pueden importar solo desde shared y al shared le aplico la regla de que puede importar de cualquier otro. Es la solución que yo aplico que seguro no será la mejor pero la idea viene de las propias implementaciones de los monorepos. Igual @CodelyTv crea otro plugin para esto 😉
Que fuerte
Se oye bonito pero hay casos donde tienes que ponerte el arma en la cabeza y acoplar tu código con un framework:
- si usas angular por ejemplo, hasta los html están plagados por su sintaxis y javascript ni se diga...
- si usas hibernate/spring sus anotaciones están regadas por todo el código...
La arquitectura expuesta te ayuda a migrar librerías, versiones y extender servicios cómodamente, pero cambiar de frameworks es otra cosa, porque por lo general ellos se ramifican en todo el código y no en un único punto... por ejemplo si el módulo de "ventas" depende del módulo "productos" y quieres eliminar spring en este último, lo más seguro es que vas a tener que modificar "ventas" también y todos los que dependen de "productos"
Hexagonal está bien para sacar lo del dominio y de la capa de aplicación y poco más. Lo que tengas acoplado a la infraestructura, ahí se queda.
la capa de aplicacion debe de manejar transaccionalidad?, pregunto porque en si en la capa de application van los casos de uso que pasa si quiero conectar mas de 2 casos de uso a otro caso, lo ideal seria una facadaa?, si es asi en que capa iria la facada?
Esta genial, me gustaria ver un ejemplo en angular
cuales son los iconos y temas que usan en el visual studio code? gran video
Si utilizo un Framework cómo Nestjs para el manejo de inyección de dependencias en una arquitectura limpia ahí a la final no sería arquitectura limpia por qué estaria dependiendo de ese Framework no? O como se debería manejar o sería una excepción a la regla?
Claro tu aplicacion esta acoplada al framework, si quisieras migrarla a otro framework tendrias que reescribir todo devuelta
Proque mejora el codigo la organizacion de paquetes?que mas da que tenga un paquete qu se llame serivcios con una interfaz y una implmentacion a que se llame aplicacion para la intergaz y dominio para la implementacion? en que mejora eso el codigo?al final es donde pongo la clase nada mas
El ejemplo de estructura de carpetas en 7:03 me parece que enreda y hace aún menos escalable el proyecto. Porque al mismo 1er nivel (módulos), tienen "auth" y "course", y ahí están mezclando conceptos de la capa de Infra con Application, para luego a cada modulo aplicar las 3 capas nuevamente de I-A-D. Para evitar el problema inicial, sugiero no dejar en paralelo las 3 carpetas de I-A-D, sino una dentro de la otra, la de más afuera la de I, y dentro la de A, y dentro la de D, así I puede acceder a cualquier capeta de A haciendo import de 'application1/recurso', y lo mismo cuando algo de Application quiera acceder a un recurso del Domain. Y cada carpeta de nivel tendrá acceso solo a su capa, sin tener que ir a buscar cosas a un nivel superior con '../../'
Interesante ver un ejemplo con python
Me sorprende mucho que digan que se enseñe mal y ese primer scafolding que pusieron para ejemplificar, siempre la he usado como la tercera imagen, se puede mejorar su verificador? No se mucho javascript pero de algoritmo si y de logica cual es su repo?
En el caso de un proyecto de front seguiría la misma estructura de carpetas?
Por si te pudiera ayudar, yo lo he aplicado en front igual, la infraestructura tiene la misma razón de ser, solicitar y persistir datos pero en vez de a una BD puede ser a una api o memoria o lo que tu necesitas.
@@kodenix Entiendo y en cuanto a por ejemplo components/pages/hooks/contexts etc entraria en la carpeta de cada uno o en un directorio nuevo llamado por ejemplo ui
@@initiald2297 Todos los elementos que comentas forman parte de tecnología especifica de la capa de boundary,presentacion o como quieran verlo segun que arquitectura. En cualquier caso podrías crear un directorio "presentation" y meter ahí todo lo que interactúa con el usuario. ¿Por que no UI?, porque si fueces otro tipo de aplicación, ejemplo una API no le llamarías vistas a los controladores que manejan las peticiones HTTP o lo que sea que realiza un actor ->"otra aplicacion" (pero en el fondo son las vistas que ataca el cliente), por lo tanto podrias llamarle presentation o boundary, como quieras. pienso que mas importante es entender que pongas el nombre que ponga sepas que responsabilidades cumplen los elementos que se encuentran en cada capa.
Olvidé comentar que en el caso de un framework ya sea backend o frontend, ya traen una estructura de proyecto pero eso no quita que todos los elementos que crees una organizacion de tus capas dentro de la carpeta de codigo de tu framework, un ejemplo que vale para Angular y Nest es crear la estructura de carpetas presentation, infrastructure, domain, application dentro de src y mover los componentes, modulos, servicios, controladores por defecto que tare el framework a presentation. De esta forma aprovechas el esquema de herramientas del framework y tienes tu lógica aislada de tecnología
Estaria muy bueno un ejemplillo con algun framework de frontend :)
Por si a alguien le vale, para aplicarlo con cualquier framework tanto en frontend como backend, yo uso dos formas (con o sin monorepo). Con monorepo es sencillo, una aplicacion ej: Angular, React, NestJS, etc y en librerias dejo la aplicación POTOJO (Plain Object Typescript OR Javascript Object 🤣) con los casos de uso, etc. Sin monorepo por ejemplo tanto en Angular como en NestJS, dentro de src me creo un directorio contexts o logic y ahí meto el POTOJO, si el día de mañana me lo tengo que llevar a otro framework, pues es solo copiarlo. Es importante aclarar que todas las implementaciones de acceso a datos, a tecnología, etc las implemento en el propio framework.
@CodelyTv los cursos en su pagina estan en español? en que lenguaje se enseña lo de los patrones ?
Exactamente, todo en español 🙂
@@CodelyTV y en qué lenguaje explican el de patrones de diseño ?
CodelyTV por qué no tienen un podcast alguna plataforma con Spotify o Apple podcast?
esperando el linter para Go
Hola tengo una duda la Hexagonal es la misma que Onion ?
Yeah!!, y que Clean y que la futura nueva arquitectura. Si miras con perspectiva de principios de diseño a todas las arquitecturas por capas, verás los principios de alta cohesión, bajo acoplamiento, de dependencias y abstracciones estables, etc, etc, etc.
ohhhh, feline
Donde esta el curso?
bit.ly/linting-js 🙂
alguien sabe el nombre de la fuente que usa en intellij?
Dani Mono 🙂
@@CodelyTV gracias
La clean architecture tiene sub arquitecturas? Y la hexagonal es una de estas o no entendí
Correcto! Clean Architecture es un tipo de arquitecturas, entre las que se encuentra la hexagonal 😊
Buen vídeo pero ojalá y nos escuchen y hagan un ejemplo más práctico sobre esta arquitectura, también me sorprende que no usan dark theme en nada jaja cuidado con los ojos chicos
Me gusto mucho esa estructura de carpetas para las Clean Architectures, pero me quedé con una duda, en esa estructura ¿donde iría la interface del CommanBus? debería ir en la capa de aplicación, pero no pertenece a ninguno de los bounded context, por eso mi duda. Saludos 🤞
En la parte final del video cuando dentro de la capa de Aplicación llaman a userRepository que es parte del Dominio, ¿Como es que el Dominio hará el guardado si está desacoplado de la capa Infraestructura? Entiendo que el dominio no debe conocer nada de Infraestructura.
Leyendo un poco más entendí que el Dominio no se conecta directamente a Infraestructura si no que usa un puerto o interfaz que se conecta a un adapter y en la infraestructura es donde se hace la implementación.
Los frameworks permiten cambiar de base de datos
Acoplarse a un framework es en síntesis lo mismo que acoplarse a una base de datos. Ambas pertenecen a la capa de infra
En realidad el orm que te brinda el framework permite cambiar de base de datos, podrias hacer tu app sin depender de un framework e integrando el orm que vos quieras manualmente a tu proyecto
Buenas, creo que hacéis muy buenos vídeos, pero siempre se habla de la ley de la dependencia, separar infra de dominio, etc. Lo que pasa es que, al aplicarlo, hay problemas que aún no están claros como resolverlos. Por ejemplo, un problema que me encuentro mucho es... Como desde infrastructura consigo referencias a la application para mandarle mensajes, tengo un service locator? hay un event bus com comandos? Metemos un sistema de inyección de dependencias? Y luego, como avisa la aplicación después de realizar las operaciones de negocio con el dominio a la infrastructura, para que, por ejemplo, muestre algo por pantalla, tenemos todo acoplado a interfaces, pero quien es el encargado de instanciar las implementaciones concretas y asignárselas por el constructor a todos los interactors/controllers/como queráis llamarle a los casos de uso, y eso también con los daos o repositorios, etc. molaría demasiado que resolvierais todas esas dudas.
Eso es lo que nunca dicen, porque este tipo de "arquitecturas" o "patrones de diseño" no existen más que en un mundo ideal, sólo sirven para resolver problemas de aprendizaje, en el mundo real la arquitectura se debe de adaptar al proyecto, no al revés.
Y los analizadores estáticos
En Android clean architecture es lo más adecuado
Cuando hablan del error casi al final del video, era porque la capa de aplicación estaba importando de la capa de infraestructura, cierto? Es decir la capa de Aplicación solo debe tener conocimiento de ella misma y de dominio...
Si
Inyección de dependencias basicamente... deberian es hacer un breve ejemplo real o con arquitecturas que muestren no tan de imagenes y explicaciones.
Hola...hay un problema en la página de cursos con los enlaces ...si uno entra a "DDD en TypeScript: Modelado y arquitectura"
Y va a abajo y clickea en el enlace de arquitectura hexagonal no va a donde debería...sino que te lleva al curso de SOLID...saludos...
Tipica optimization temprana que caus mas problemas de los que soluciona.
Siempre es mejor enseñar el código en lugar de hablar de las teorías. y al menos enseñando el código escrito con tecnologías modernas.
No os olvidéis de PHP 😭, que es como empezasteis
Semana que viene verás cositas de ello 😬
@@CodelyTV Que ganas tengo
no me gusta el fondo y las letras borrosas con el eflecto glitch quedan horribles
Muy buena la explicación pero hay que reducir las dependencias, un plugin que te ayude a forzar una estructura de directorios? Totalmente innecesario
Rafa hablas muy rápido tío 🤣
Totalmente 😂
plandemia coleguis
No hay nada nuevo, solo cambios de nombres.
La verdad interesante video pero no se entiende nada
Malísimo el ejemplo de Laravel. Justamente Lo que da la estabilidad e independencia del motor de BBDD es Eloquent, que asume la responsabilidad de envolver la base de datos de manera abstracta. De hecho los repos son casi un antipatrón en Laravel, porque al final terminas usando el repo como un proxy a Eloquent y los modelos. En general hay demasiado overkill tratando de montarse sobre la arquitectura del framework con resultados desastrosos.
Otro aspecto que sería bueno tratar es que habeis tenido que dar demasiadas explicaciones para establecer el patrón, es decir, no hay ·Convention" y si mucha "Configuration". Just think about this. Usualmente las soluciones buenas son evidentes, obvias, y no requieren de tantos artefactos para arraigar.
Ya veo muchos junior confundiendo y pidiendo ejemplos de arquitecturas en la capa presentacional… 👎