¡Gracias por esas palabras, capo! Me alegra muchísimo poder ayudar y compartir lo que sé con todos los que están arrancando, porque sé lo que es empezar desde cero. La idea es que nadie se quede atrás y que todos tengamos las mismas oportunidades para crecer en este mundo del desarrollo. Así que seguí metiéndole con todo, que acá estamos para aprender juntos. ¡A romperla!
Saludos, gracias por tu contenido... me gustaria preguntarte que opinas de esta definición de caso de uso: "Un caso de uso es una especificación de secuencias de acciones, incluyendo variaciones, que el sistema puede realizar y que dan un resultado observable de interés a un actor particular. El actor típicamente necesitará casos de uso para soportar su trabajo para crear, cambiar, seguir, borrar o estudiar objetos de negocio"
@@javiopakan2 yo lo pondría más como "un caso de uso es una unidad de lógica de aplicación que describe el flujo de interacciones y reglas que transforman los datos de entrada en resultados significativos para un actor, manteniendo la independencia de las dependencias externas. su objetivo es soportar las necesidades del actor relacionadas con los objetos de negocio de forma coherente y reutilizable." esto asegura que estás separando la lógica de negocio del resto del sistema (por ejemplo, ui, base de datos, etc.), que es uno de los principios más importantes en clean architecture.
Brother buenas tardes , Con respecto a el ejemplo de la cuenta bancaria , A mi parecer si existiría una forma de limitar Técnicamente la validación de si una persona es mayor a 18 años ,Definiendo un requisito que solicite una consulta a la base de datos o API de la Registraduría Nacional del Estado Civil de tú país y si existes en la base de dato de acuerdo a tu Número de Identificación , En ese momento , Puedes dar apertura una Cuenta Bancaria , Muchas gracias por el video brother
Hola Alan, ¿qué opinas acerca de usar patrones de diseño dentro del frontend junto con la clean arquitecture. Por ejemplo, usar el patrón repository para desacoplar las peticiones y desacoplar la librería con la que se hacen las peticiones y/o usar el patrón de inyección de dependencias con el mismo objetivo de desacoplar los layers de la clean arquitecture? ¿Crees que sea redundante o que aumente la complejidad del desarrollo? Desde mi punto de vista, creo que sería más mantenible y escalable, además de que sería muy fácil de testear debido a que es mucho más sencillo mockear una clase que una librería o petición, pero no sé si valga la pena debido a que llegue a ser muy complejo. Muchas gracias por el gran valor de tu contenido
Esta perfecto ! Justo en mi primer video comento que un patrón de diseño no es una arq. Un patrón es un conjunto de buenas prácticas que dan solución a un problema muy recurrente y se pueden aplicar tranquilamente en cualquier proyecto independientemente de su arquitectura
Me da la sensación que es una pérdida de tiempo y un dolor de cabeza implementar clean architecture. Me cuesta ver los beneficios, sobretodo con el uso de microservicios o un front con componentes, la atomicidad ya la tenes. Me imagino que tiene sentido en un monolito bastante grande, pero de otra manera no lo veo práctico. Quizás necesito casos prácticos en donde se haya implementado para darle valor. Saludos
Coincido con vos, hay que tener en cuenta que llevar a cabo un diseño de arquitectura de inicio a fin es volverse completamente loco, yo optaría por tomar "cositas" que realmente aporten valor y adaptarlas a la necesidad, por ejemplo, si no tenés definida tu DB, utilizaría el patrón repository. Por otro lado, pensar en utilizar Clean Architecture en cada microservicio -por mas diminuto que sea- es una locura, yo utilizaría un MVC para los servicios mas diminutos/simples y quizás una estrategia similar a esta para un servicio donde se concentre lógica fuerte.
Es un gran depende ! La clean architecture es más para proyectos grandes, cuando ya tienes mucha lógica y debes sectorizarla, también tiene su costo y queda en uno ver si vale la pena los beneficios. Para proyectos chicos no creo que sea lo mejor. La principal idea de la clean architecture es separar las cosas de tal manera que sean intercambiables en caso de que el día de mañana algo cambie o se vea afectado por alguna condición externa. Todo esto se verá más claro en vídeos siguientes donde veremos en parte práctica su implementación y dará mucho más sentido en su forma de trabajarla. Yo creo que se verá como algo muy natural ya verán
@@maxxi_dev el repository por lo general con los frameworks tipo Laravel o NET que traen Eloquent o Entity Framework es reinventar la rueda y colocarsela encima a esos ORM que en sí ya tienen implementado el patrón repository internamente, la DB no cambia nunca y si cambia se le indica al ORM cual motor se va a usar y listo. Para mi lo que sí hay que mantener aislado es el dominio, lo demás se modulariza y según la ocasión se usa ORM y si es necesario usar repository porque no lo salva el ORM pues se usará en el modulo que corresponda.
Cuando trabajamos en proyectos de tamaño considerable y según las necesidades del mismo, el arquitecto puede a su criterio entender que existe la necesidad de velar por la mantenibilidad y/o adaptabilidad del código, entiende que dada la naturaleza del proyecto es un MUST para la viabilidad del mismo. Supongamos un cliente quiere realizar una plataforma de pagos online. Esta puede estar atada a las disposiciones legales del país sobre el cual opera, estar integrado con sistemas fiscales, bancarios, servicios de terceros, etc. Si nuestro código esta acoplado a las implementaciones locales / actuales de estos sistemas, el día que cambien, probablemente no vamos a ser capaces de adaptarnos al cambio, porque va a haber que modificar una gran parte del sistema o hacerlo de 0. Ej: Abrir operaciones en otro país. Va a implicar nuevas integraciones, nuevas reglas impositivas, etc. Si tu código está altamente acoplado a las implementaciones de tu país de origen lo vas a tener que tirar. Para eso sirve la arquitectura limpia y creo es un must conocerla al menos, ya sabrás cuando aplicarla, no es para todo.
tremendo hecho para nada obvio super interesante: 12:19 " LA UX ES UNA LIMITACION DE LA APLICACION " :O epico... si vas comprendiendo y abstrayendo el video hasta esa parte se te vuela la peluca.
@@JoelPasapera no necesariamente, pero debería ser lo más estable y consistente posible, ya que representa el núcleo del negocio. el dominio no es "inmutable" en el sentido literal (como un objeto en programación funcional), pero su diseño busca minimizar los cambios porque cualquier modificación en el dominio puede tener un impacto significativo en todo el sistema.
Que suerte que existen personas como Alan que tiran toda esta data gratis para los que venimos de abajo y estamos arrancando. Un crack.
¡Gracias por esas palabras, capo! Me alegra muchísimo poder ayudar y compartir lo que sé con todos los que están arrancando, porque sé lo que es empezar desde cero. La idea es que nadie se quede atrás y que todos tengamos las mismas oportunidades para crecer en este mundo del desarrollo. Así que seguí metiéndole con todo, que acá estamos para aprender juntos. ¡A romperla!
que buen ejemplo lo del console.log(a) me termino de aclarar todo.
Gracias Alan , se aprende un montón sobre estos temas importantes con tus vídeos ❤
Super, info puntal como siempre.
Estoy siguiendo esta "list" de una manera emocionante !!
Saludos, gracias por tu contenido... me gustaria preguntarte que opinas de esta definición de caso de uso:
"Un caso de uso es una especificación de secuencias de acciones, incluyendo variaciones, que el sistema puede realizar y que dan un resultado observable de interés a un actor particular.
El actor típicamente necesitará casos de uso para soportar su trabajo para crear, cambiar, seguir, borrar o estudiar objetos de negocio"
@@javiopakan2 yo lo pondría más como
"un caso de uso es una unidad de lógica de aplicación que describe el flujo de interacciones y reglas que transforman los datos de entrada en resultados significativos para un actor, manteniendo la independencia de las dependencias externas. su objetivo es soportar las necesidades del actor relacionadas con los objetos de negocio de forma coherente y reutilizable."
esto asegura que estás separando la lógica de negocio del resto del sistema (por ejemplo, ui, base de datos, etc.), que es uno de los principios más importantes en clean architecture.
Que libro recomiendas para profundizar sobre esto de las arquitecturas?
Genial ! no sabia lo del Content Layout Shift !
Brother buenas tardes , Con respecto a el ejemplo de la cuenta bancaria , A mi parecer si existiría una forma de limitar Técnicamente la validación de si una persona es mayor a 18 años ,Definiendo un requisito que solicite una consulta a la base de datos o API de la Registraduría Nacional del Estado Civil de tú país y si existes en la base de dato de acuerdo a tu Número de Identificación , En ese momento , Puedes dar apertura una Cuenta Bancaria , Muchas gracias por el video brother
Hola Alan, ¿qué opinas acerca de usar patrones de diseño dentro del frontend junto con la clean arquitecture. Por ejemplo, usar el patrón repository para desacoplar las peticiones y desacoplar la librería con la que se hacen las peticiones y/o usar el patrón de inyección de dependencias con el mismo objetivo de desacoplar los layers de la clean arquitecture? ¿Crees que sea redundante o que aumente la complejidad del desarrollo? Desde mi punto de vista, creo que sería más mantenible y escalable, además de que sería muy fácil de testear debido a que es mucho más sencillo mockear una clase que una librería o petición, pero no sé si valga la pena debido a que llegue a ser muy complejo. Muchas gracias por el gran valor de tu contenido
Esta perfecto ! Justo en mi primer video comento que un patrón de diseño no es una arq. Un patrón es un conjunto de buenas prácticas que dan solución a un problema muy recurrente y se pueden aplicar tranquilamente en cualquier proyecto independientemente de su arquitectura
Es más, es muy común ver dentro de una arq hexagonal o clean el patrón proxy por ejemplo
¿domain es igual a entities?
@@dei8bit el dominio contiene las entities
Me da la sensación que es una pérdida de tiempo y un dolor de cabeza implementar clean architecture. Me cuesta ver los beneficios, sobretodo con el uso de microservicios o un front con componentes, la atomicidad ya la tenes.
Me imagino que tiene sentido en un monolito bastante grande, pero de otra manera no lo veo práctico.
Quizás necesito casos prácticos en donde se haya implementado para darle valor.
Saludos
Coincido con vos, hay que tener en cuenta que llevar a cabo un diseño de arquitectura de inicio a fin es volverse completamente loco, yo optaría por tomar "cositas" que realmente aporten valor y adaptarlas a la necesidad, por ejemplo, si no tenés definida tu DB, utilizaría el patrón repository.
Por otro lado, pensar en utilizar Clean Architecture en cada microservicio -por mas diminuto que sea- es una locura, yo utilizaría un MVC para los servicios mas diminutos/simples y quizás una estrategia similar a esta para un servicio donde se concentre lógica fuerte.
Es un gran depende ! La clean architecture es más para proyectos grandes, cuando ya tienes mucha lógica y debes sectorizarla, también tiene su costo y queda en uno ver si vale la pena los beneficios. Para proyectos chicos no creo que sea lo mejor.
La principal idea de la clean architecture es separar las cosas de tal manera que sean intercambiables en caso de que el día de mañana algo cambie o se vea afectado por alguna condición externa.
Todo esto se verá más claro en vídeos siguientes donde veremos en parte práctica su implementación y dará mucho más sentido en su forma de trabajarla. Yo creo que se verá como algo muy natural ya verán
@@maxxi_dev el repository por lo general con los frameworks tipo Laravel o NET que traen Eloquent o Entity Framework es reinventar la rueda y colocarsela encima a esos ORM que en sí ya tienen implementado el patrón repository internamente, la DB no cambia nunca y si cambia se le indica al ORM cual motor se va a usar y listo. Para mi lo que sí hay que mantener aislado es el dominio, lo demás se modulariza y según la ocasión se usa ORM y si es necesario usar repository porque no lo salva el ORM pues se usará en el modulo que corresponda.
@@GentlemanProgramming muchas gracias por responder, espero los siguientes videos para ver la implementacion en un caso de ejemplo, saludos!
Cuando trabajamos en proyectos de tamaño considerable y según las necesidades del mismo, el arquitecto puede a su criterio entender que existe la necesidad de velar por la mantenibilidad y/o adaptabilidad del código, entiende que dada la naturaleza del proyecto es un MUST para la viabilidad del mismo. Supongamos un cliente quiere realizar una plataforma de pagos online. Esta puede estar atada a las disposiciones legales del país sobre el cual opera, estar integrado con sistemas fiscales, bancarios, servicios de terceros, etc. Si nuestro código esta acoplado a las implementaciones locales / actuales de estos sistemas, el día que cambien, probablemente no vamos a ser capaces de adaptarnos al cambio, porque va a haber que modificar una gran parte del sistema o hacerlo de 0. Ej: Abrir operaciones en otro país. Va a implicar nuevas integraciones, nuevas reglas impositivas, etc. Si tu código está altamente acoplado a las implementaciones de tu país de origen lo vas a tener que tirar. Para eso sirve la arquitectura limpia y creo es un must conocerla al menos, ya sabrás cuando aplicarla, no es para todo.
Nada, sigo perdido
tremendo hecho para nada obvio super interesante: 12:19
" LA UX ES UNA LIMITACION DE LA APLICACION " :O
epico...
si vas comprendiendo y abstrayendo el video hasta esa parte se te vuela la peluca.
El dominio es inmutable 🧐🧐
@@JoelPasapera no necesariamente, pero debería ser lo más estable y consistente posible, ya que representa el núcleo del negocio. el dominio no es "inmutable" en el sentido literal (como un objeto en programación funcional), pero su diseño busca minimizar los cambios porque cualquier modificación en el dominio puede tener un impacto significativo en todo el sistema.
🤣