Qué es Clean Architecture ? cómo aplicarlo a tu aplicación Front End ? 

La capa de adaptadores es un concepto genial, la gente no se da cuenta, pero sirve bastante, ya sea para migrar(API, Base de datos o lo que sea) o cosas así.

Por favooooor haz un curso sobre clean Architecture y explicalo mientras desarrollas un pequeño proyecto front y back. Excelente video

Buenas! excelente vid. Estoy metiendome en el mundo de la clean architecture. Actualmente estoy trabajando en un proyecto Angular y .NET Core con microservices... que se subestimó y terminó siendo ENORME. Nos encontramos con todos los problemas que enumeraste, desde testing dificil hasta super high coupling. Cambias una cosa y tenes que cambiar 5 componentes jajaj. Tengo varias preguntas pero principalmente 2... Tenes alguna referencia o sitio donde se pueden encontrar ejemplos practicos de clean architecture especificamente en Angular? y la 2da, en este proyecto se implementa NGRX para el state management. y estoy teniendo dificultades en el analisis de como implem,entar ngrx con clean architecture, dado que ngrx tiene partes en cada uno de los layers... alguna reocmendación?

Muy bueno!! Estoy estudiando este tema y lo entendí muy bien con este video. Un clarisimo ejemplo de dependencia circular es la serie de Netflix: Dark!!!

Laburo con Angular y sé a qué te referís jaja. Excelente video!!

Que buena explicación 🙌

Gracias por el video, me ha aclarado muchas otras cosas adicionales de esto de la "arquitectura limpia". Por cierto... hmmm, tanto angular, react, vue y otros parecidos, son lenguaje JavaScript, cada uno es un Framework de JavaScript. bueno, tambien se puede usar typescript, pero sigue siendo JavaScript. Yo en esto, no sé sí llamarlo arquitectura o no, más bien, como tu dices, lo veo como una serie de normas, una guía. Se supone, yo uso MVC como patrón de desarrollo, digo "supuestamente", porque a lo mejor he entendido mal porque todo apuntan a que esto de la arquitectura Hexagonal o limpia, o la DDD, son totalmente diferentes, y yo los veo igual. Que opinas al respecto, cual sería en realidad la diferencia? Por cierto, desarrollo fulstack en PHP(back), JavaScript, HTML, mi forma de desarrollo la estoy llevando ahorita a Node.js, espero en algún momento a otros lenguajes o frameworks fullstack

Por que se dice que el dominio no se toca. En un proyecto que trabajo el problema que me encuentro es que constantemente me piden modificar las entidades, es decir, agregar quitar campos, crear nuevas tablas o modificar las existentes y precisamente es lo que más problemas genera.

Shrek no dijo lo de las capas, lo dijo el burro. XD

Es una mala referencia, el codigo spaghetti vino por el uso de los GOTO, hacer saltos en el codigo. Y eso hacia el codigo complicado. Y cdo se uso en decoupling es pq era complicado ( y una mala referencia). Me da gracia tambien que has dicho el API Rest de toda la vida jejeje, se nota que tengo mas anhos, hay otras cosas mas viejas que API Rest de toda la vida jejeje . 👴😅

Yo empece hace poco a implementar clear arquiteture en mis proyecto y no tenia claro el concepto del dominio.. ya me queda un poco claro

Yo tengo un critica eres muy crack muchas gracias por explicarlo xD

Excelente, todo super entendible!

muito bom, obrigada por falar devagar, brasileiros agradecem kakakaka

Una corrección, lo correcto cuando se habla de temperatura es hablar de grados Celsius y no centígrados.

Hola, tengo una duda, si tengo un UseCase1 que maneja la lógica de negocio del entity1, este UseCase1 puede llamar a UseCase2 o no ?

pense que era un video de rappi

Que buena bajada de data hno!

Si en el Dominio estan las reglas de negocio(segun clean-arq). Pero los Dominios son Entidades (o sea al fin clases de un lenguaje que responden a un negocio) Entonces Las reglas de negocio no estarian en realidad en Application layer.?? dado que es la layer en la que iteratuen y se orquesten los dominios ? Para mi el dominio no es mas que una clase con atributos adaptado a neceidades de negocio (no digo que sean DataEntities ..ojo), pero el negocio en si esta en los Use Cases.. .. Me cuesta quitarme la mentalidad retro de SOA + n-tear del 2000 jjaja Saludos buen video

Muy buen video, una pregunta ¿Tienes algun repo de clean architecture en angular?

ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-vRGVnqylO68.html Yo en el núcleo normalmente ponía todo lo que vaya a utilizar en diversos módulos/características de la aplicación(como componentes atómicos, por ejemplo).

Estan buenos lo ejemplos y consejos!

Genio del alma, clase magistral la tuya, algun material teorico que recomiendes para profundizar mas sobre la Clean Architecture? Se que hay un libro con ese titulo literal pero no sé si te estas basando en ese exactamente. Gracias!

Muy bueno.

esto esta muy bueno pero para mi concepto aprendo haciendo un proyecto sencillo, pero que aporta al conocimiento grandeza

Buen intento de adapatar patrones de clean architecture a FrontEnd pero no cuaja tiene errores groseros en tus ejemplos. 1) Das como ejemplos que los plain objects del modelo serian como Entities (en tu diagrama sañalado como Enterprise Bussines Rules) pero te digo que en ese caso tus entidades serian un Anitpattern "Anemic Domain Model" descrito por Martin Fowler. lo cual es el corazon de cualquier clean architectura que la logica este ahi. 2) Definis que los adaptares o puertos como simples translates entre el modelo externo y el del dominio y dejas de lado las librerias, lo importante es no estar acoplado a una libreria como Axios, y que vos tengas un contrato en tu dominio que te desacople, ahora para lograr eso no tenes que meter un boilerplate cuando tenes 1=1 entre el front (cliente) y api backend (servidor), ya que te gusta traslador conocimientos no olvides la I de Solid "Interface segregation" las interfaces son de los clientes. Dicho esto es totalmente prematuro que pongas ese codigo cuando no es necesario. Lo otro que no hablas como temas mas importanto de los adpatodores que es qeu se puedan doblar para realizar testing. Por ultimo esto no quiere decir que no se puedan aplicar en muchas soluciones patrones de clean architecture, y es una charla que podriamos tener pero ya te digo que un CustomHook del tipo UseClient que tenga logica de negocio es mas representativo de un Domain Entity que tu Modelo anemico de plain objects. Saludos.

Muy desordenada la explicación. Poco estructurada.

No entendiste nada. Please, releé el libro. Tené cuidado con lo que explicás, hay gente que va a tomar esto como referencia.