No hay nada perfecto y esta bien que tengas tu opinión. Al fin y al cabo las arquitecturas solo son opiniones de como hacer las cosas. En mi caso me gusta bastante clean architecture y lo único malo que le encuentro puede ser solamente tener en cuenta tomarse un poco mas de tiempo en hacer las cosas.
Yo hago clean architecture, pero no la cumplo a raja tabla, primero porque me cuesta aplicarlo a raja tabla (quiza mea culpa por falta de habilidad) y la otra porque con el tiempo algunas partes la considero innecesaria. Entonces lo que aplico son principios de clean architecture, creo que el mejor ejemplo es el que muestra Fernando Herrera en el curso de Flutter. Pasa que te vuelves loco cuando aparecen cosas como los agregados... Si te pegas a fidelidad lo terminas complejizando Pero no soy el mejor ejemplo en estos dias me hice una libreria y todo era funciones y me resolvia el problema. Tambien sabia que no le iba a dar mantenimiento
Primeramente te felicito por lo que haces, faltan contenidos de calidad en español sobre temas de programación. Ahora, entiendo tu punto de vista, sin embargo el error y trampa reside en decir :"este proyecto no va a creer tanto". Esto nunca lo sabes, a menos que seas un viajero del tiempo. A menos que sea una empresa grande, la mayoría de los grandes proyectos empiezan como proyectos muy pequeños y se les van agregando "features" a como van necesitando con el paso del tiempo. No hay un momento exacto en que tu proyecto pasa de pequeño a grande, es gradual (a menos que empezó ya siendo grande). Entonces, desde mi punto de vista vale la pena meter una arquitectura robusta desde el inicio aunque te tome un poco más de tiempo ya que te va a costar mucho más hacerlo en etapas tardías ( si llega a crecer). Los cambios en un proyecto se vuelven más complicados conforme el proyecto crezca, a menos que tengas una arquitectura ideal que te resuelva está parte. Y otra cosa, yo tengo 10 años en el sector y nunca me he topado con un proyecto con una arquitectura demasiado robusta para el tamaño del proyecto pero con una gran cantidad de proyectos que "no iban a crecer tanto" y terminan siendo monstruos con arquitectura inadecuada. En algún punto, optan por crear un proyecto alterno ( con la arquitectura adecuada) y al mismo tiempo mantener el proyecto "legacy" mientras se migran ( a veces dura mucho así). Mi conclusión, vale la pena invertir más tiempo al principio y tener una arquitectura "sobrada" que tener que hacerlo después y al mismo mantener un "legacy". ¡Saludos!
Por eso es bueno conocer varias, muchos proyectos pequeños salen con MVC y ya cuando la cosa crecer, si es bueno pensar en otras cosas, también luego de mucho pensar y mucha practica uno va aprendiendo a decidir y ver que no existe un martillo de oro en la programación.
Es cierto, no toda arquitectura se aplica a todo proyecto. Por ejemplo, un api que se dedique a solo enviar emails, no va a tener persistencia de datos, sin embargo sí una resiliencia, entonces una clean architecture no se adapta al 100% a este api.
Estoy de acuerdo con la afirmación mas no con el ejemplo, como tengo entendido, las capas no representan un "algo absoluto", por ejemplo, la capa Infraestructura se encarga de la comunicación que se hace hacia afuera, esto puede ser tanto una BD como consumos de API en el caso de tu ejemplo, notificacion por email, es decir, la persistencia y el envío de email compartirían la capa, sin embargo, para el caso que planteas en efecto no valdría la pena implementar Clean, sería como usar una bomba para matar una mosca.
@@julianlopez1610 por eso el ejemplo así, ahí es donde se utilizaría el patron adaptador para poder tener una librería que haga uso de ese api, podría ser utilizando refit y en la capa de infraestructura o de application se puede utilizar esa parte, aunque yo optaría más para utilizarla en la capa de appllication ya que se puede usar con mediatr para su notificación. Por otro lado, el api de solo mensajería optaría por algo mucho mucho más simple.
Yo solia ser el vato que siempre queria apegarse a solid y clean architecture y llegue al punto de hacer sobre ingenieria en cosas que realmente eran sencillas y no requerian de tanto, ahora ya trato de equilibrar esa parte de mi jaja
Buenas. Estoy de acuerdo con varias de tus posturas, y con respecto a otras, entiendo muy bien tu posición. Gracias por este vídeo, para mí es muy importante conocer el parecer de gente que está más en el hacer que en el mero saber. Saludos.
Hace unos minutos estaba hablando con un compa sobre que "recomienda" aprender ya estando dentro de la industria. Mis consejos fueron 2: -Architecture -Cloud Todo tiene sus contras, pero como hablaste en un video reciente: "aprender arquitectura cubrirá el vacío que nuevos programadores no pueden cubrir aún" así que mi conclusión es, aplicar arquitectura en ocasiones es sobre-ingeniería, en otras ocasiones te ahorrará tiempo, dinero, y sobre todo te brindará escalabilidad
Hector, estoy de acuerdo para un proyecto pequeño no es necesario una arquitectura limpia, pero como desarrolladores de software ya no debemos hacer código monolítico (es diferente hacer arquitecturas monolíticas). Te felicito por tu curso y lo estoy llevando.
No todo es microservicio por cuestiones de recursos y complejidad. Más bien la norma es monolítico y algunas reglas de negocio implementadas con microservicios
Muy buen video te sigo por tu claridad al comunicar las cosas y porque las bajas a un plano más cotidiano, me intereso lo de programación funcional para crear métodos más genéricos, si tenes algún link de algún video tuyo con más detalles por favor pásemelo
parcero saludos desde colombia ✌️ el en el libro por alla cuando toca el capitulo de empaquetamientos por layer, feature, component comenta que todo el libro no se trata de algo estricto como de "esta es la solucion definitiva" sino como algo que se implementa segun necesidad, algo progresivo. lo mismo cuando habla de evitar la ansiedad de unificar todo (la parte que habla de la duplicidad real o falsa). personalmente no lo vi colo un libro purista, pero bueno, queria compartir eso 👍 saludos.
Interesante video, Clean Architecture es una arquitectura solo para casos empresariales donde los procesos de negocio deben de cumplirse de forma estricta. un gusto ver tus video.
En mi experiencia, suelo aplicar Clean Architecture en todo menos en lambdas, puesto que estas sí son demasiado pequeñas como para que en un cambio significativo sea más sencillo cambiar la lambda entera. Recientemente pasó que me pidieron una API para aplicar promociones en base a compras realizadas, esta API tenía que usar DocumentDB como database y así fue. Después de varios temas con el arquitecto y los administradores de bases de datos, llegaron a la conclusión de que no se iba a permitir el uso de DocumentDB por no ser relacional y al tener las reglas del negocio separadas de las dependencias, pude cambiar de base de datos en menos de 2 horas. Era una aplicación pequeña, solamente 5 endpoints y el login, sin embargo, aplicar buenas prácticas, que es lo que fomenta Clean Architecture, hace que los cambios no sean tan significativos a nivel código como parecería.
Es cierto nunca se puede ser purista con las arquitecturas siempre hay que adaptarlas al software que tenemos yo solo aplico este tipo de arquitectura cuando se que algun sistema va estar en cambios constantes y para otros proyectos los patrones de diseño o el mismo MVC son de mucha utilidad
Ninguna arquitectura es mala o es el que aplica dicha arquitectura desconoce los detalles de dicha arquitectura que usa. Esto lo aprendí en un curso de gestión de proyectos dictado por un general formado en west point y ustedes dirán y esto que tiene que ver, que para que un proyecto funcione tu debes contratar al que mas conoce una herramienta y puso un ejemplo: te tienen que operar, a quien elijes; a uno recién salido de la especialización que a estudiado mucha cirugía de alta especialización o un cirujano de 20 o 30 años operando.
Para embedded systems donde los recursos son tan limitados es prácticamente impossible en ciertos casos. No digo que siempre, a veces como mencionas en sistemas grandes vale la pena y es robusto, pero para microcontroladores con unos cuantos MBs de storage no tiene mucho sentido.
Eso no quita que no puedas hacer port and adapters en embedded, puedes hacer en embedded codigo super legible, mantenible, testable y escalable. Creo que aqui tenemos que empezar antes todo con la honestidad y siendo humildes. Si no entiendes una arquitectura vale que no la apliques fielmente pero criticarla tampoco porque justo tu critica en mayor medida vendra por desconocimiento de la arquitectura en si misma que por una realidad absoluta de tener fundamentos para invalidarla.
justo tenía planeado comprarme ese libro, pero estoy ponderando cual debo adquirir primero, clean code, clean architecture o desing patters de Erich Gamma. ¿por cual me sugieres empezar?
Buen video Héctor, tengo también tu curso de Udemy (todavia menos de la mitad) y esta muy bueno. Solo que siendo sincero pense que iba a ser un curso de nivel intermedio para adelante. Aveces es difícil encontrar cursos que no te quieran explicar desde que es una variable y el proyecto final un CRUD sencillo. Saludos.
Estoy de acuerdo con minimizar mapeos y minimizar capas. Pero no solo para proyectos "grandes". En general, en cualquier proyecto si minimizas capas haces menos compleja la aplicación. Pero entre más separes el sistema en servicios es más dificil gestionar el estado. La cosa es que los ORM fomentan un diseño rígido del negocio.
Siempre se dice que ciertos tipos de arquitectura no se ajustan o no valen la pena en proyectos medianos o pequeños, eso es correcto, y creo que todos lo tienen claro, pero ahí es cuando muchas veces el ego del desarrollador (o del equipo en si) no le deja asumir que su proyecto es pequeño, y sin más análisis de van de cabeza en arquitectura limpia, DDD, o incluso micro servicios donde no era necesario. Cómo definir la envergadura necesaria para un tipo de arquitectura? Tamaño del equipo o gente que lo toca (en mi caso somos cientos de devs tocando un mismo código, con TBD), concurrencia (unos cientos de usuarios al día, o millones al mismo tiempo?), cantidad de vistas o features, etc. Estoy seguro que ni la mitad de los proyectos que la mayoría trabaja bastaban con un monolito
yo uso clean architecture para todo, eso si no hago separacion de modulos como mencionan que los modulos se tienen que conectar solo por medio de adapatadores, lo hago porque me facilita el testing
Yo estoy de acuerdo con varios puntos. Me gustaria agregar algo mas, desde mi punto de vista. Y es que habria que hacer enfoque en la solucion de la Clean Archtecture. Que nos soluciona? Bien se da a entender al final del video de manera implicita, pero habria que hacer mas incapie. Y basicamente es que la app este preparada PARA LOS CAMBIOS. Y aca es el punto en el que no estoy de acuerdo con algo que dice sobre proyectos pequeños. Los proyectos pequeños suelen ser los mvp, algo que creas como emprendedor, etc. Y es ahi donde debes implementar una infra fexible. Por ejemplo me paso a mi en un proyecto personal, que se me empezo a ser costoso mantener una app con una base de datos en particular y por la correcta arquitectura, el migrar a otra DB, fue muy facil. Y aca hay otro punto, el tema adapters. Adapters es algo costoso, que en TU VIDA te vas arrepentir de hacerlo. Y es mas, me gustaria saber a que se refiere con el ejemplo que da sobre el cambio en una prop de DB porque ese problema es una de las grandes soluciones que te da los adapters. Los adapters son LO MAS!!! Me gusto mucho el video!! No suelen a ver opiniones objetivas en estos tiempos, no solo en el ambito de la programacion, sino en todos los topicos contemporaneos...la gente repite repite repite y no se detiene 1 minutos analizar lo que se esta diciendo. Y he visto videos de algunos youtubers conocidos (no voy a nombrar) dandole a la clean Architecure EXAGERADAMENTE que ni en empresas gigantezcas (trabajo en una de ellas) los suelen hacer. Y ademas cada vez que sacan un video nuevo agregan o sacan cosas.
Entiendo lo que comentas sobre que en ciertas ocasiones se complica el querer forzar la arquitectura a la implementación basada en x framework, pero después de montar varios proyectos y adaptarlo a los frameworks creo que el problema es que no llegamos a entender bien al framework y sus capacidades. Respecto al ejemplo que pones con EntityFramwork de si la implementación dejarla en la capa de domino y no sacarla la capa de infraestructura, en ese ejemplo en concreto si que se puede hacer aplicando algunos patrones de diseño. El tema es que muchas veces esos frameworks han pervertido la manera en la que se hacen las cosas en POO y muchos solo seguimos las guías y ejemplos que ponen en las documentaciones del framework de turno.
entonces hay algunas arquitecturas, implementaciones y herramientas que no son necesarias aplicarlas y que de hacerlo se caeria en sobre ingenieria puesto que se intentaria forzar el uso de algo que no lo amerita. Por ejemplo aplicar la arquitectura de clean arquitecture en un proyecto muy pequeño. En resumen, ser pragmatico es mas importante que seguir recomendaciones generales.
Oye hdeleonnet, habría forma de que esto de clean architecture lo pudieras explicarlo pero mostrando un proyecto junto con su código??. Porque te podría entender, pero ya viendolo en un ejemplo real, nos podías dar un perspectiva más amplia de esta situación
Pregunta, asumiendo que creas un mvp y hace una arquitectura no se mvc y la rompe, ahora constantemente tienes que crear nuevas features, y que haces en esos caso re escribir todo para mejorar la arquitectura ? Gastar en manos por que no te alcanza el tiempo entre crear nuevas features y crear la nueva arquitectura, no es mejor siempre empezar con una buena arquitectura dese el inicio
Estoy de acuerdo que una clean architecture no va servir para todo tipos de proyectos, pero yo no diría que solo si es un proyecto grande si no mas bien un proyecto muy cambiante. Por ejemplo un proyecto pequeño pero que esta en constante cambio si le viene bien una clean architecture.
Pues creo que puedes usar clean en todos los proyectos, solo que se tarda mas en desarrollar porque hay que seguir reglas. Las interface adapters se necesitan para pasar los dto a objects domains, a lo mejor no necesitas todo el dto que te da ese provider (http, queue kafka o lo que sea) y por eso este mapper Patron facade? Guay pero que tengas un cajon de sastre como patron me da la sensacion mas de antipatron, tu montate algo para relacionarte con el caos y luego ya veremos (nunca se llega a revisar) es un poco meh En el gateway se pueden usar programacion OO como un metodo getUserByFilter y la implementacion que filtre como quiera pero ya lo tienes mas abierto y tu caso de uso lo dejas extensible y verboso a mas filtros Lo dicho, hacemos ingenieria y no solo codigo y por ende tenemos que pensar en el futuro y en los otros devs que pasen por ahi.. si se hace todo porque si nunca tenemos tiempo para ordenar la casa.. Dejo mi gusta por hablar del tema que pocos se atreven!!❤
al principio cuando lei el titulo. Dije no, no se puede criticar clean arquitecture. Personalmente soy muy fan de esto, asi como los patrones de diseño, tambien principioa solid etc.. Pero viendo el video todo me parecio razobable y logico
hay que ser pragmático y no puristas. clean arch. son para empresas donde el perfil de ingenieros es semi senior , llegando a senior y senior. porque como decis , todos se trata de negocios y tiempo. si las empresas implementa clean arch, significa que pagan por esa complejidad , de lo contrario te vas a encontrar con sistemas mas sencillos pero igual de funcionales.
Excelente video publicitario 👌 En mi experiencia, si alguna técnica no ofrece ventajas claras no vale la pena aplicarla. Igual nada sirve si no se tiene la disciplina y sabiduría para hacer los ajustes en el código en el momento justo. Por otra parte en cuanto Clean Architecture hay un punto que nadie menciona y es que pasa cuando el equipo no tiene conocimientos de Clean Architecture y los obligan a utilizarla, en mi experiencia he visto que el proyecto se retraza mucho y genera mucha frustacion.
C9mo siempre el mas heater como yo los problemas de java y arquitectos espagueti que se queden en java y en esaa arquitecturas Zig tenemos otros para que nos den sus soluciones sin sentido em este contexto. Buen video
La programación y desarrollo debería ser más fácil día con día no más difícil, hay muchas arquitecturas y patrones de diseño y bla bla bla osea están bien. Al final de cuentas no hay una regla general y estricta. Pienso que el mejor patrón o arquitectura siempre es el que le queda mejor al modelo de negocio de lo que estás desarrollando, en el caso de Facebook por ejemplo que tuvieron que incluso Innovar sobre lenguajes y frameworks existentes. Al desarrollar y mantener el código tu mismo te vas dando cuenta qué es lo mejor para el proyecto sin necesidad de implementar a rajatabla lo que dicen los libritos y los eruditos de arquitectura de software.
Cuando veo videos de Clean Architecture es con ese diagrama, pero en los vídeos con código lo que veo es una solución con las capas Presentation, Application, Domain e Infrastructure y también le llaman Clean Architecture. Eso me tiene confundido
El diagrama mostrado aquí es el original, todo lo demás son sinónimos. En el curso explico a detalle esa situación, quizá pase esa explicación a RUclips.
Regla #1 de arquitectura de software: no hay bala de plata para resolver todos los problemas técnicos, enfócate en la esencia de la arquitectura, no en los detalles.
El mismo tío Bob ha dicho que no hay soluciones perfectas y pues de eso se trata la ingeniería. Ventajas y desventajas. Pragmatismo a final de cuentas.
Que moco otro comentario, Creo que la logica del proyecto siempre estar en un paquete Aparte, no casarlo con el Framework para que no se te pudra, entonces en ese paquete aparte usa el patron o la arquitectura que quieras, quedando responsable de como se manejan los datos. Y en el framework llamas eso... si te toca cambiar de framework no se perdio el trabajo y puedes migrar facil
Clean architecture y hexagonal es literalmemte lo mismo, se puede resumir en el principio "escribe codigo para una interfaz, no para una implementación" (patrones de diseño) y si lo analizas bien descubres que todo es un mvc con interfaces que ahora le llaman adapters..., no hay una verdadera novedad, solo es una reinterpretacion. Por otro lado no son una arquitectura en sí, en realidad son un estilo arquitectónico, pueden consultar diferentes definiciones de arquitectura de software. Por encima de clean architecture y hexagonal, pondria el libro de RUP allí si podran observar la diferencia entre un estilo y una arquitectura y como se construye la misma a traves de casos de usos, leeanlo es coool.
jajajajajajajaja nunca escuche a nadie mandar tan a la vrg4 a la gente usando un simple "me da igual" cuando vengan a hablar de purismo jajajajajajajajaja
Estoy muy de acuerdo con lo que dices el problema es que a menudo te encuentras con opiniones muy extremas y es prácticamente imposible imponer un criterio de hacer las cosas simples. Mejor me estoy enfocando en saber más tecnologías y le dejo el diseño de arquitectura a los radicales 😂
Mis Cursos de Programación: hdeleon.net/cursos-premium/
Mi Libro de Programación: hdeleon.net/libro-aprender-a-programar-con-c-hector-de-leon/
jajajaj el Rapunzel de la programación!
No hay nada perfecto y esta bien que tengas tu opinión. Al fin y al cabo las arquitecturas solo son opiniones de como hacer las cosas.
En mi caso me gusta bastante clean architecture y lo único malo que le encuentro puede ser solamente tener en cuenta tomarse un poco mas de tiempo en hacer las cosas.
Yo hago clean architecture, pero no la cumplo a raja tabla, primero porque me cuesta aplicarlo a raja tabla (quiza mea culpa por falta de habilidad) y la otra porque con el tiempo algunas partes la considero innecesaria. Entonces lo que aplico son principios de clean architecture, creo que el mejor ejemplo es el que muestra Fernando Herrera en el curso de Flutter. Pasa que te vuelves loco cuando aparecen cosas como los agregados...
Si te pegas a fidelidad lo terminas complejizando
Pero no soy el mejor ejemplo en estos dias me hice una libreria y todo era funciones y me resolvia el problema. Tambien sabia que no le iba a dar mantenimiento
Primeramente te felicito por lo que haces, faltan contenidos de calidad en español sobre temas de programación.
Ahora, entiendo tu punto de vista, sin embargo el error y trampa reside en decir :"este proyecto no va a creer tanto". Esto nunca lo sabes, a menos que seas un viajero del tiempo. A menos que sea una empresa grande, la mayoría de los grandes proyectos empiezan como proyectos muy pequeños y se les van agregando "features" a como van necesitando con el paso del tiempo. No hay un momento exacto en que tu proyecto pasa de pequeño a grande, es gradual (a menos que empezó ya siendo grande). Entonces, desde mi punto de vista vale la pena meter una arquitectura robusta desde el inicio aunque te tome un poco más de tiempo ya que te va a costar mucho más hacerlo en etapas tardías ( si llega a crecer). Los cambios en un proyecto se vuelven más complicados conforme el proyecto crezca, a menos que tengas una arquitectura ideal que te resuelva está parte.
Y otra cosa, yo tengo 10 años en el sector y nunca me he topado con un proyecto con una arquitectura demasiado robusta para el tamaño del proyecto pero con una gran cantidad de proyectos que "no iban a crecer tanto" y terminan siendo monstruos con arquitectura inadecuada. En algún punto, optan por crear un proyecto alterno ( con la arquitectura adecuada) y al mismo tiempo mantener el proyecto "legacy" mientras se migran ( a veces dura mucho así).
Mi conclusión, vale la pena invertir más tiempo al principio y tener una arquitectura "sobrada" que tener que hacerlo después y al mismo mantener un "legacy".
¡Saludos!
Por eso es bueno conocer varias, muchos proyectos pequeños salen con MVC y ya cuando la cosa crecer, si es bueno pensar en otras cosas, también luego de mucho pensar y mucha practica uno va aprendiendo a decidir y ver que no existe un martillo de oro en la programación.
Es cierto, no toda arquitectura se aplica a todo proyecto.
Por ejemplo, un api que se dedique a solo enviar emails, no va a tener persistencia de datos, sin embargo sí una resiliencia, entonces una clean architecture no se adapta al 100% a este api.
Estoy de acuerdo con la afirmación mas no con el ejemplo, como tengo entendido, las capas no representan un "algo absoluto", por ejemplo, la capa Infraestructura se encarga de la comunicación que se hace hacia afuera, esto puede ser tanto una BD como consumos de API en el caso de tu ejemplo, notificacion por email, es decir, la persistencia y el envío de email compartirían la capa, sin embargo, para el caso que planteas en efecto no valdría la pena implementar Clean, sería como usar una bomba para matar una mosca.
@@julianlopez1610 por eso el ejemplo así, ahí es donde se utilizaría el patron adaptador para poder tener una librería que haga uso de ese api, podría ser utilizando refit y en la capa de infraestructura o de application se puede utilizar esa parte, aunque yo optaría más para utilizarla en la capa de appllication ya que se puede usar con mediatr para su notificación. Por otro lado, el api de solo mensajería optaría por algo mucho mucho más simple.
Yo solia ser el vato que siempre queria apegarse a solid y clean architecture y llegue al punto de hacer sobre ingenieria en cosas que realmente eran sencillas y no requerian de tanto, ahora ya trato de equilibrar esa parte de mi jaja
Buenas. Estoy de acuerdo con varias de tus posturas, y con respecto a otras, entiendo muy bien tu posición. Gracias por este vídeo, para mí es muy importante conocer el parecer de gente que está más en el hacer que en el mero saber. Saludos.
Recomiendo el contenido del Rapunzel de la programación. Necesita más gatitos
Hace unos minutos estaba hablando con un compa sobre que "recomienda" aprender ya estando dentro de la industria. Mis consejos fueron 2:
-Architecture
-Cloud
Todo tiene sus contras, pero como hablaste en un video reciente: "aprender arquitectura cubrirá el vacío que nuevos programadores no pueden cubrir aún" así que mi conclusión es, aplicar arquitectura en ocasiones es sobre-ingeniería, en otras ocasiones te ahorrará tiempo, dinero, y sobre todo te brindará escalabilidad
Gracias a este video , ya me animé a leer el libro de '"El programador pragmático" , nunca hay que ser intensos en nuestras ideas
Hector, estoy de acuerdo para un proyecto pequeño no es necesario una arquitectura limpia, pero como desarrolladores de software ya no debemos hacer código monolítico (es diferente hacer arquitecturas monolíticas). Te felicito por tu curso y lo estoy llevando.
No todo es microservicio por cuestiones de recursos y complejidad. Más bien la norma es monolítico y algunas reglas de negocio implementadas con microservicios
Muy buen video te sigo por tu claridad al comunicar las cosas y porque las bajas a un plano más cotidiano, me intereso lo de programación funcional para crear métodos más genéricos, si tenes algún link de algún video tuyo con más detalles por favor pásemelo
Que buen, pero buen video y que grandiosa explicación.. dejo dos likes..
parcero saludos desde colombia ✌️ el en el libro por alla cuando toca el capitulo de empaquetamientos por layer, feature, component comenta que todo el libro no se trata de algo estricto como de "esta es la solucion definitiva" sino como algo que se implementa segun necesidad, algo progresivo. lo mismo cuando habla de evitar la ansiedad de unificar todo (la parte que habla de la duplicidad real o falsa).
personalmente no lo vi colo un libro purista, pero bueno, queria compartir eso 👍
saludos.
El video fue hecho con ese objetivo, muchos que lo leen se lo toman como ley
Lo importante es entender la idea general, con tal que le de sentido al código y ayude a mantener y escalar, en el camino la misma complejidad lo pide
estoy haciendo el curso en este momento...sigo aprendiendo ❤
Interesante video, Clean Architecture es una arquitectura solo para casos empresariales donde los procesos de negocio deben de cumplirse de forma estricta.
un gusto ver tus video.
Cómo puedes estar en contra de nuestro sensei Tio Bob. Mal muy mal. (sarcasmo)
En mi experiencia, suelo aplicar Clean Architecture en todo menos en lambdas, puesto que estas sí son demasiado pequeñas como para que en un cambio significativo sea más sencillo cambiar la lambda entera.
Recientemente pasó que me pidieron una API para aplicar promociones en base a compras realizadas, esta API tenía que usar DocumentDB como database y así fue. Después de varios temas con el arquitecto y los administradores de bases de datos, llegaron a la conclusión de que no se iba a permitir el uso de DocumentDB por no ser relacional y al tener las reglas del negocio separadas de las dependencias, pude cambiar de base de datos en menos de 2 horas. Era una aplicación pequeña, solamente 5 endpoints y el login, sin embargo, aplicar buenas prácticas, que es lo que fomenta Clean Architecture, hace que los cambios no sean tan significativos a nivel código como parecería.
Es cierto nunca se puede ser purista con las arquitecturas siempre hay que adaptarlas al software que tenemos yo solo aplico este tipo de arquitectura cuando se que algun sistema va estar en cambios constantes y para otros proyectos los patrones de diseño o el mismo MVC son de mucha utilidad
Ninguna arquitectura es mala o es el que aplica dicha arquitectura desconoce los detalles de dicha arquitectura que usa. Esto lo aprendí en un curso de gestión de proyectos dictado por un general formado en west point y ustedes dirán y esto que tiene que ver, que para que un proyecto funcione tu debes contratar al que mas conoce una herramienta y puso un ejemplo: te tienen que operar, a quien elijes; a uno recién salido de la especialización que a estudiado mucha cirugía de alta especialización o un cirujano de 20 o 30 años operando.
Hola Pelón, por tu culpa estoy aprendiendo C# y .Net, ahora tendré que aprender clean arquitecture. Por cierto, gran video tirando factos. ❤
Para embedded systems donde los recursos son tan limitados es prácticamente impossible en ciertos casos. No digo que siempre, a veces como mencionas en sistemas grandes vale la pena y es robusto, pero para microcontroladores con unos cuantos MBs de storage no tiene mucho sentido.
Eso no quita que no puedas hacer port and adapters en embedded, puedes hacer en embedded codigo super legible, mantenible, testable y escalable.
Creo que aqui tenemos que empezar antes todo con la honestidad y siendo humildes. Si no entiendes una arquitectura vale que no la apliques fielmente pero criticarla tampoco porque justo tu critica en mayor medida vendra por desconocimiento de la arquitectura en si misma que por una realidad absoluta de tener fundamentos para invalidarla.
justo tenía planeado comprarme ese libro, pero estoy ponderando cual debo adquirir primero, clean code, clean architecture o desing patters de Erich Gamma. ¿por cual me sugieres empezar?
Buen video Héctor, tengo también tu curso de Udemy (todavia menos de la mitad) y esta muy bueno. Solo que siendo sincero pense que iba a ser un curso de nivel intermedio para adelante.
Aveces es difícil encontrar cursos que no te quieran explicar desde que es una variable y el proyecto final un CRUD sencillo.
Saludos.
Te recomiendo terminarlo, sobre todo la parte 9 y 10 son mucho más allá de básico
Para un proyecto pequeño se podría usar el patrón repositorio y servicio
Que grande HDeLeon !
El curso es muy bueno yo voy por la mitad, lo bueno del curso es que es con ejemplos reales y practicos muchas gracias por compartir!
Gracias a ti
Estoy de acuerdo con minimizar mapeos y minimizar capas. Pero no solo para proyectos "grandes". En general, en cualquier proyecto si minimizas capas haces menos compleja la aplicación. Pero entre más separes el sistema en servicios es más dificil gestionar el estado. La cosa es que los ORM fomentan un diseño rígido del negocio.
Siempre se dice que ciertos tipos de arquitectura no se ajustan o no valen la pena en proyectos medianos o pequeños, eso es correcto, y creo que todos lo tienen claro, pero ahí es cuando muchas veces el ego del desarrollador (o del equipo en si) no le deja asumir que su proyecto es pequeño, y sin más análisis de van de cabeza en arquitectura limpia, DDD, o incluso micro servicios donde no era necesario. Cómo definir la envergadura necesaria para un tipo de arquitectura? Tamaño del equipo o gente que lo toca (en mi caso somos cientos de devs tocando un mismo código, con TBD), concurrencia (unos cientos de usuarios al día, o millones al mismo tiempo?), cantidad de vistas o features, etc. Estoy seguro que ni la mitad de los proyectos que la mayoría trabaja bastaban con un monolito
yo uso clean architecture para todo, eso si no hago separacion de modulos como mencionan que los modulos se tienen que conectar solo por medio de adapatadores, lo hago porque me facilita el testing
Estas siendo pragmático para tu contexto, y eso es lo que importa.
Tu contenido es excelente.
con el chiste del principio ha ganado mi like sr
Yo estoy de acuerdo con varios puntos. Me gustaria agregar algo mas, desde mi punto de vista. Y es que habria que hacer enfoque en la solucion de la Clean Archtecture. Que nos soluciona? Bien se da a entender al final del video de manera implicita, pero habria que hacer mas incapie. Y basicamente es que la app este preparada PARA LOS CAMBIOS. Y aca es el punto en el que no estoy de acuerdo con algo que dice sobre proyectos pequeños. Los proyectos pequeños suelen ser los mvp, algo que creas como emprendedor, etc. Y es ahi donde debes implementar una infra fexible. Por ejemplo me paso a mi en un proyecto personal, que se me empezo a ser costoso mantener una app con una base de datos en particular y por la correcta arquitectura, el migrar a otra DB, fue muy facil.
Y aca hay otro punto, el tema adapters. Adapters es algo costoso, que en TU VIDA te vas arrepentir de hacerlo. Y es mas, me gustaria saber a que se refiere con el ejemplo que da sobre el cambio en una prop de DB porque ese problema es una de las grandes soluciones que te da los adapters. Los adapters son LO MAS!!!
Me gusto mucho el video!! No suelen a ver opiniones objetivas en estos tiempos, no solo en el ambito de la programacion, sino en todos los topicos contemporaneos...la gente repite repite repite y no se detiene 1 minutos analizar lo que se esta diciendo. Y he visto videos de algunos youtubers conocidos (no voy a nombrar) dandole a la clean Architecure EXAGERADAMENTE que ni en empresas gigantezcas (trabajo en una de ellas) los suelen hacer. Y ademas cada vez que sacan un video nuevo agregan o sacan cosas.
Me refería que en algunos proyectos tener adapters para todo No aplica, no todo es web, hay proyectos de IoT o videojuegos.
@@hdeleonnet perfecto, bien entendido! Saludos!
Excelente, cuando lei sobre la hexagonal.. cuando puedas.. jaja
En pocas palabras, el código y arquitecturas deben trabajar para ti y no tu para ellos
Entiendo lo que comentas sobre que en ciertas ocasiones se complica el querer forzar la arquitectura a la implementación basada en x framework, pero después de montar varios proyectos y adaptarlo a los frameworks creo que el problema es que no llegamos a entender bien al framework y sus capacidades. Respecto al ejemplo que pones con EntityFramwork de si la implementación dejarla en la capa de domino y no sacarla la capa de infraestructura, en ese ejemplo en concreto si que se puede hacer aplicando algunos patrones de diseño. El tema es que muchas veces esos frameworks han pervertido la manera en la que se hacen las cosas en POO y muchos solo seguimos las guías y ejemplos que ponen en las documentaciones del framework de turno.
entonces hay algunas arquitecturas, implementaciones y herramientas que no son necesarias aplicarlas y que de hacerlo se caeria en sobre ingenieria puesto que se intentaria forzar el uso de algo que no lo amerita. Por ejemplo aplicar la arquitectura de clean arquitecture en un proyecto muy pequeño. En resumen, ser pragmatico es mas importante que seguir recomendaciones generales.
Hola Héctor podrías decirnos en qué orden recomiendas realizar tus cursos 🤘🏼🤘🏼🤘🏼🤘🏼
Curso C# por los fundamentos
Curso de Patrones de Diseño
Curso Backend
Clean Architecture
Oye hdeleonnet, habría forma de que esto de clean architecture lo pudieras explicarlo pero mostrando un proyecto junto con su código??. Porque te podría entender, pero ya viendolo en un ejemplo real, nos podías dar un perspectiva más amplia de esta situación
Pues el curso que lance hacemos eso.
@@hdeleonnet pero este video esta en youtube
Ah
Pregunta, asumiendo que creas un mvp y hace una arquitectura no se mvc y la rompe, ahora constantemente tienes que crear nuevas features, y que haces en esos caso re escribir todo para mejorar la arquitectura ? Gastar en manos por que no te alcanza el tiempo entre crear nuevas features y crear la nueva arquitectura, no es mejor siempre empezar con una buena arquitectura dese el inicio
Un MVP es para tirarse a la basura, por eso es un MVP
El luchador de la programación
Tal cual
Estoy de acuerdo que una clean architecture no va servir para todo tipos de proyectos, pero yo no diría que solo si es un proyecto grande si no mas bien un proyecto muy cambiante.
Por ejemplo un proyecto pequeño pero que esta en constante cambio si le viene bien una clean architecture.
Pues creo que puedes usar clean en todos los proyectos, solo que se tarda mas en desarrollar porque hay que seguir reglas.
Las interface adapters se necesitan para pasar los dto a objects domains, a lo mejor no necesitas todo el dto que te da ese provider (http, queue kafka o lo que sea) y por eso este mapper
Patron facade? Guay pero que tengas un cajon de sastre como patron me da la sensacion mas de antipatron, tu montate algo para relacionarte con el caos y luego ya veremos (nunca se llega a revisar) es un poco meh
En el gateway se pueden usar programacion OO como un metodo getUserByFilter y la implementacion que filtre como quiera pero ya lo tienes mas abierto y tu caso de uso lo dejas extensible y verboso a mas filtros
Lo dicho, hacemos ingenieria y no solo codigo y por ende tenemos que pensar en el futuro y en los otros devs que pasen por ahi.. si se hace todo porque si nunca tenemos tiempo para ordenar la casa..
Dejo mi gusta por hablar del tema que pocos se atreven!!❤
kotlin y Java. A veces omito los casos de uso, pero adoro las interfaces.
al principio cuando lei el titulo. Dije no, no se puede criticar clean arquitecture. Personalmente soy muy fan de esto, asi como los patrones de diseño, tambien principioa solid etc.. Pero viendo el video todo me parecio razobable y logico
😅😅😅 justo ahora estoy haciendo un worker service que se conecta con Graph Api y no necesito todas las capas XD...
hay que ser pragmático y no puristas. clean arch. son para empresas donde el perfil de ingenieros es semi senior , llegando a senior y senior. porque como decis , todos se trata de negocios y tiempo. si las empresas implementa clean arch, significa que pagan por esa complejidad , de lo contrario te vas a encontrar con sistemas mas sencillos pero igual de funcionales.
Excelente video publicitario 👌
En mi experiencia, si alguna técnica no ofrece ventajas claras no vale la pena aplicarla. Igual nada sirve si no se tiene la disciplina y sabiduría para hacer los ajustes en el código en el momento justo.
Por otra parte en cuanto Clean Architecture hay un punto que nadie menciona y es que pasa cuando el equipo no tiene conocimientos de Clean Architecture y los obligan a utilizarla, en mi experiencia he visto que el proyecto se retraza mucho y genera mucha frustacion.
Si, es un punto que no mencione, la curva de aprendizaje, pero esto puede ser algo normal no solo para Clean architecture
Simplemente es agarrar las cosas buenas o que te sirvan y aplicarlas
el software es un ser vivo que hay que cuidar y mantener
excelente video
Hermoso video, estuve esperando que alguien dijera la triste realidad de ese libro.
Jajajajaj "El Raspunsel de la programación" 😂😂😂
Jajajajaja el rapunzel de la programación jaajaja ese Hector me mata!
Aprovecha lo bueno , desecha lo que no sirve...todo cambia con el tiempo, en informatica no podemos casarnos solo con una cosa
Las intros de lo mejor del canal, jaja 🤣🤣
C9mo siempre el mas heater como yo los problemas de java y arquitectos espagueti que se queden en java y en esaa arquitecturas Zig tenemos otros para que nos den sus soluciones sin sentido em este contexto. Buen video
Todo debe estar equilibrado
Buen video.
Yo al inicio del video: ¿De que crj esta hablando?
Yo al final del video: ¿De que crj esta hablando?
Esto que voy a decir va más allá de la programación. Vivimos en la era de la sacralización del método y la relativización del resultado.
La programación y desarrollo debería ser más fácil día con día no más difícil, hay muchas arquitecturas y patrones de diseño y bla bla bla osea están bien. Al final de cuentas no hay una regla general y estricta. Pienso que el mejor patrón o arquitectura siempre es el que le queda mejor al modelo de negocio de lo que estás desarrollando, en el caso de Facebook por ejemplo que tuvieron que incluso Innovar sobre lenguajes y frameworks existentes. Al desarrollar y mantener el código tu mismo te vas dando cuenta qué es lo mejor para el proyecto sin necesidad de implementar a rajatabla lo que dicen los libritos y los eruditos de arquitectura de software.
Cuando veo videos de Clean Architecture es con ese diagrama, pero en los vídeos con código lo que veo es una solución con las capas Presentation, Application, Domain e Infrastructure y también le llaman Clean Architecture. Eso me tiene confundido
El diagrama mostrado aquí es el original, todo lo demás son sinónimos. En el curso explico a detalle esa situación, quizá pase esa explicación a RUclips.
Expectacular
Impresionante.
Ah no, verdad que este es el peludo, no el pelado.
Mi dev evil , saca las playeras en negro por favor
muy buen análisis del libro, no es bueno ser tan purista, saludos
A mi me gusta la clean pero esta bien, muy lindo cabello hahaha
EL purismo extremo es como el Ouroboros, una serpiente que se come la cola, mas en un lenguaje tan especial como C#...
Regla #1 de arquitectura de software: no hay bala de plata para resolver todos los problemas técnicos, enfócate en la esencia de la arquitectura, no en los detalles.
El mismo tío Bob ha dicho que no hay soluciones perfectas y pues de eso se trata la ingeniería. Ventajas y desventajas. Pragmatismo a final de cuentas.
Usar clean arquitecture para todo es el antipatrón Martillo de Oro.
Creo que las fachadas son ampliamente usadas en Laravel
Que moco otro comentario, Creo que la logica del proyecto siempre estar en un paquete Aparte, no casarlo con el Framework para que no se te pudra, entonces en ese paquete aparte usa el patron o la arquitectura que quieras, quedando responsable de como se manejan los datos. Y en el framework llamas eso... si te toca cambiar de framework no se perdio el trabajo y puedes migrar facil
Chevere
Hector me das un cupón de descuento para tu curso de Clean Architecture en Udemy porfa 🥲🥲🥲
Mañana lanzó y los pongo por aquí
Clean architecture y hexagonal es literalmemte lo mismo, se puede resumir en el principio "escribe codigo para una interfaz, no para una implementación" (patrones de diseño) y si lo analizas bien descubres que todo es un mvc con interfaces que ahora le llaman adapters..., no hay una verdadera novedad, solo es una reinterpretacion.
Por otro lado no son una arquitectura en sí, en realidad son un estilo arquitectónico, pueden consultar diferentes definiciones de arquitectura de software.
Por encima de clean architecture y hexagonal, pondria el libro de RUP allí si podran observar la diferencia entre un estilo y una arquitectura y como se construye la misma a traves de casos de usos, leeanlo es coool.
great
ok, voy a seguir poniendo todas las reglas de negocio en el formulario de mi proyecto de winforms
Creo que el presentador está confundiendo cosas. Uno son los conceptos y desiciones y otra cosa es la implementación.
PeludoNerd
Que guapa rapunzel
el rapunzel no mames jajaja
empezó mi novela :v
Rapunzel 😂
Lo malo es no conocerlo 😂
creo que estas describiendo arquitectura hexagonal
Clean Architecture nació de Arquitectura Hexagonal.
-"Tu me la inyectas" 🥵
A la mierda el fanatismo, purismo y mesianismo
jajajajajajajaja
nunca escuche a nadie mandar tan a la vrg4 a la gente usando un simple "me da igual" cuando vengan a hablar de purismo jajajajajajajajaja
Estoy muy de acuerdo con lo que dices el problema es que a menudo te encuentras con opiniones muy extremas y es prácticamente imposible imponer un criterio de hacer las cosas simples. Mejor me estoy enfocando en saber más tecnologías y le dejo el diseño de arquitectura a los radicales 😂