Arquitectura Limpia: Un ejemplo práctico con Spring Boot

[@carlosvillegas33]

nunca veo video largos, y hoy me enganche en la explicación, agradezco mucho el trabajo invertido en enseñarnos.

[@emanuelvallejo5705]

Llevo un mes buscando un vídeo de este en español y sale este crack

[@leonardof02]

En serio ofreces contenido de calidad hermano, basado en la experiencia de trabajo en el campo de batalla, tengo ya un poco de experiencia y hay poco contenido en internet para subir de nivel, realmente tu lo logras demasiado bien, felicidades!!

[@josue10hd]

rayos este video vale oro! los 41 minutos mejor invertidos de toda mi vida, suscrito!

[@TellevoTellevo]

Debo decir nuevamente, Crack, muy claro gracias a ti estoy teniendo un verdadero placer al programar con esta arquitectura, de hecho el tema del @UseCase me parece extraordinario, mucho mas claro

[@prezdev]

voy en el minuto 18. Muy buena explicación. Muchas gracias por el contenido!

[@JoseMGT-mn3in]

Excelente explicación, Gracias!!!!!!!!

[@juani221287]

Este canal es excelente!! No me hice fan, me hice adicto jaja... Ofrece Data de mucho nivel y muy valiosa!!!

[@ManuelSanchez-lg9cv]

Éste man es un duro, va conciso y al grano sin tanto rodeo. Excelentes videos!!!

[@gonzalooviedo5435]

Te ganaste un suscriptor, MUY POCOS hablan de temas tan complejos como este con la sencillez que lo has explicado, dando un ejemplo muy practico y a la vez muy sencillo, sinceramente, FELICITACIONES!. Vi todo el video eh!, buenisimo.

[@ferneyra10]

Excelente explicación. Me gusta la solución que da con el uso de la anotación @UseCase porque de esta manera solo hay un solo lugar donde modificar sí deseamos utilizar algún otro framework, pero en el sentido estricto creo que estamos violando la regla de dependencia (Infrastructure -> Application -> Domain), ya que cuando crea la anotación (@UseCase) dentro de la capa de aplicación también hay una dependencia hacia la capa de Infrastructure (Spring). Creo que una posible solución a esto, es declarando un bean de tipo SendMoneyService dentro de una clase con la anotación @Configuration dentro de la capa de infraestructura. Esto requiere más código pero de esta forma no hay ninguna referencia hacia Spring dentro de la capa de Application.

[@xermimartinez1961]

Me parece muy muy interesante la propuesta que haces. Una de las cosas con las que llevo tiempo obsesionado, es ver de qué manera poder desacoplar también la capa de aplicacióndel framework usado, puesto que siendo puristas con las arquitecturas limpias, las menciones al framework deberían quedar únicamente en la capa más exterior. No obstante, en todos los ejemplos y tutoriales que encuentro, en pro de la eficiencia, se acaba contaminando ligeramente la capa intermedia con detalles del framework. Siguiendo tu propuesta, ¿te refieres básicamente a tener una clase "wrapper" en la capa de infraestructura que sea un Bean de la clase de la capa intermedia a la cual queremos aplicarle beneficios de Spring como la gestión por parte de este framework de los coponentes de este tipo?

[@ferNeyra100]

@@xermimartinez1961 No es un wrapper. Seria algo como lo siguiente: @Configuration public class BeanConfiguration { @Bean SendMoneyPort getMoneyPort(LoadAccountPort loadAccountPort, UpdateAccountPort updateAccountPort){ return new SendMoneyService(loadAccountPort, updateAccountPort); } }

[@ferneyra10]

Elimina mis respuestas, creo que no le gustó lo que comente 🥺

[@andreszapatadev9024]

Que buen video, he visto muchos a hablar del tema y nunca terminar de entenderlo correctamente, ahora creo que puedo ponerlo en práctica en un proyecto en curso, Gracias saludos desde Colombia

[@andresgroveralbinochambi4589]

Te agradezco mucho la explicación, y es justamente donde trabajo, que tenemos que implementar una arquitectura de este tipo. Muchas gracias nuevamente por la explicación. Ahora si entendí bien su implementacion.

[@alexdev__]

Naaa loco, te felicito... Es oro puro lo que compartes, antes no sabia o no podia entender como estructurar mi proyecto pero ahora con este video pude entenderlo!!

[@chopsuey167]

Excelente explicación! En mi actual trabajo manejamos la arquitectura de esta forma y la verdad trae muchas ventajas sobretodo cuando es más que simples CRUDs.

[@Cuzcator]

Excelente, gracias por la explicación, me queda mucho más claro ahora. Solo tengo una duda, en el ejemplo tiene un Service SendMoneyService, para lo cual tienes una interfaz SendMoneyPort y en el Service lo implementes, mi duda es, si deseo agregar un nuevo caso de uso, por ejemplo, ShowMovements, debo crear un Service ShowMovementService y un puerto ShowMovementPort?

[@GROOVETECHSETS]

Mil gracias por este vídeo. La calidad del contenido de tu canal es increible!

[@jhecohe]

Simple, concreto y muy útil, muchas gracias, excelente video

[@ftwtf]

pedazo de ejemplo, necesitaba ver a alguien explicando algo asi con spring. Solo te ha faltado hacer hincapié en que todo esto de arquitectura limpia, mejora como es obvio la testabilidad en toda la aplicación, haciendo que cuesten menos esfuerzo los test unitarios por ejemplo (porque seguro que alguno trabajará sin muchos test por culpa de la mala arquitectura). saludos, ojalá hagas amplies más contenido.

[@checovel]

Muy bueno el video, me sirvió mucho para terminar de entender de manera sencilla los conceptos de arquitectura limpia, 👍

[@LeonardoPachon]

Excelente aporte. Muchas gracias! 😎

[@johanmanuelpinedahernandez7103]

Buenísimo video. Súper clara la teoría y la explicación en código. Por fin entendí el propósito de esta arquitectura

[@Jstarwin]

Excelente video , aunque se adapta mas a la arquitectura hexagonal que bien puede clasificarse como arquitectura limpia , tiene sus diferencias con el modelo propuesto por uncle bob. Seria bueno un ejemplo haciendo uso de presenter para el manejo de las respuestas del caso de uso y la implementación de dto para que en los limites de las capas no viajen las entidades de dominio.

[@marcoaurelioosoriodeleon7350]

Me parece perfecta la explicación. Ya había visto otros videos pero algo se quedaba en el tintero! Gracias!!

[@danislobaina7132]

Siempre has sido un crack, saludos hermano !!!

[@jeysonsoto5343]

Excelente contenido. Solo tengo una duda. ¿No sería mejor colocar el método de balance "isBalanceGreaterThan" dentro del método de dominio "subtract"? Esto asegura que nunca se sustraiga más de lo que se tiene en la cuenta y el caso de uso queda más limpio. Leo opiniones. Saludos.

[@AlfredeoPastor]

Está bueno el video!. El @Service no es algo de spring boot es una denominación sacada de DDD (se puede ver en los comentarios). Y si me permites yo haría una pequeña refactorización, pondría la excepción dentro del método subtract ejecutándose siempre que el resultado sea negativo (principio tell don't ask de Martin Fowler.

[@SACAViXTech]

Impresionante, no conocía el principio, me lo quedo , gracias por compartir 👍

[@dperezcabrera1]

Completamente de acuerdo, asi te proteges de los comportamientos indeseados, como que te pasen por parámetro un valor negativo.

[@Cyan69]

Hola, En el artículo de Martin Fowler donde explica este principio indica que no es algo de su cosecha y que el no lo utiliza. martinfowler.com/bliki/TellDontAsk.html Se le asocia a: This principle is most often associated with Andy Hunt and "Prag" Dave Thomas (The Pragmatic Programmers). They describe it in a IEEE Software column and a post on their website. Cito: "But personally, I don't use tell-dont-ask. I do look to co-locate data and behavior, which often leads to similar results." Independientemente de que se use o no, me ha parecido muy interesante el artículo y el vídeo y es parte de la decisión del ingeniero si desea utilizarlo o no. Les agradezco estas conversaciones tan sanas y que enriquecen mucho el canal. Un saludo.

[@TellevoTellevo]

Muchas gracias, muy util.

[@bartolomepina3844]

Excelente. Muchas gracias por compartir información tan valiosa

[@andriuxonetube]

excelente explicación y ejemplo, muchas gracias!!!

[@ocleidyreve6361]

Me parece muy bien explicada esta arquitectura, muy buen trabajo. La verdad es que este tipo de arquitectura se ve muy bien desde afuera pero una vez que empieza a crecer se vuelve tedioso basado en mi experiencia. El primer elemento criticable de este tipo de arquitectura es la organización y la cantidad de clases que genera. - Poner todo los adapters, services , etc en un mismo lugar hace que te desconcentres y te pierdas localizando tu código incluso cuando el IDE ayude. - La cantidad de clases que genera es enorme especialmente cuando tienes un negocio denso. Esto tiende a perjudicar el rendimiento y si lo combinas con el punto anterior puedes volverte literalmente loco. El segundo elemento criticable es el exceso de abstracción. - Si bien la implementación y la abstración de la capa de acceso a datos me parece bien, no veo tanta la necesidad de abstración en los casos de usos ya que casi siempre los casos de usos son concretos y realizan una acción en espécifico y además de eso usan los otros puertos para mantenerse aislados de implementaciones que no le competen. Además es considerado una mala práctica crear una abstración para algo que no sabes a ciencia cierta si puede tener más de una implementación. Este es mi criterio basado en mi experiencia, tampoco es que haya que hacerme caso 😅. Al final lo que busco es un balance entre la complejidad y la práctica basado en el caso de uso en cuestion.

[@m_i_g_u_e_l_]

Concuerdo. Algo que se puede añadir especialmente para proyectos grandes es la arquitectura Vertical Slice para organizar mejor el conjunto de clases que genera la arquitectura hexagonal

[@sinfonico1984]

Si bien todo tiene algo malo, es imperante estar atentos de cuanto es que crece nuestra solución, aveces tenemos la idea de querer hacer un micro servicio orientado a un contexto especifico y en el futuro comienza a inflarse como un monolito, en ese caso hay que preguntarse si estamos respetando los bordes de contexto.

[@sapito169]

Siempre he detestado el uso de DTOs. El Tío Bob Martin los utiliza en su arquitectura, los llama Response Model y Request Model, pero en el fondo son DTOs: clases con getters y setters. Yo sigo la regla de no utilizar DTOs a menos que exista una razón para tenerlos, como, por ejemplo, utilizar un DTO para un servicio que devuelva un listado de usuariosDTO que no tienen clave. Sin embargo, esto es totalmente opuesto a lo que hacen los demás. El resto de personas dicen que si su arquitectura utiliza DTOs, se usan DTOs en todos los lados, y solo se evitan cuando no hay otra opción. Respecto al rendimiento, hay un amplio margen para escribir un código limpio sin perjudicar el rendimiento. Digamos que tienes un procesamiento que requiere varios pasos y es pesado. No es necesario bajar por cada paso, transformarlo en un modelo de negocio, pasarlo a un servicio que lo procese, volverlo a subir para el siguiente paso, y así sucesivamente. Es mejor que el resultado final te sea retornado, y que todo se haga en un solo paso en la base de datos. Además, hago una excepción para utilizar Lombok, que es solamente una herramienta que evita tener que mantener siempre sincronizados los getters, setters, constructores y toString. Es solo un macro, así que no estoy cometiendo el error de que todo el sistema colapse por un miserable getter mal hecho que pasa desapercibido.

[@sapito169]

@@sinfonico1984 a mi me pasa lo opuesto de tener varios microservicios y todo el mundo ponen el codigo donde mejor le paresca ese dia y nadie tienen ni la menor idea de cual es el criterio unificado ni quien decide que codigo va en que microservicio

[@untalsanders]

​@@sapito169 los DTO tienen un objetivo particular y es transportar datos entre procesos para reducir el número de llamadas a métodos. Puedes llamarlos Response/Request Model o DTOs, sin embargo el cómo se llamen no cambia su objetivo. Respecto a usarlo por todos lados, estoy un poco de acuerdo, ya que si lo usas en un lado y en otro no, reduces homogeneidad en el código, y creo que eso tiende al desorden, porque si usas objetos de dominio en un lado y DTOs por otro, al final tendrías que hacer eso que dices tú que odias, que es mantener getters y setters sincronizados entre modelos y DTOs o en el peor de los casos que se te escape una campo de algún objeto de dominio y termine viajando por la red sin ningún tipo de cuidado, por ejemplo con el objeto de dominio User se te escape la password. A mi realmente lo que me trajo a los comentarios fue, ver si alguien había preguntado lo siguiente: ¿si uso DTOs en qué lugar de esta arquitectura lo pondría? siempre he tenido ese debate con colegas. ¿los DTOs son parte del dominio, o de application o en este caso particular son parte de los adaptadores, y si son adaptadores qué tipo de adaptador serían de entrada o de salida? En un MVC tradicional normalmente paquetizamos por concepto, es decir, cada clase atiende a un concepto particular, una clase es un controlador, otra es un servicio y así sucesivamente. Y en este caso particular se suele tener un paquete `dtos` sin embargo en la arquitectura planteada por Yoandy realmente no se dónde ubicar los DTOs, por eso mi inquietud. @SACAViXTech te agradezco si puedes darme una luz con esto y de paso muchas gracias por tan valioso aporte a la comunidad.

[@otoniel_pm]

Excelente video, muchísimas gracias!! Generalmente no veo videos en español porque tienden a enfocarse en contenido por junior, pero este es la excepción!

[@aleckvinent]

más claro ni el agua!!! excelente charla

[@steelseries8862]

Muy buen contenido, toda la parte teorica me ayudo muchisimo, ya cuando vino el codigo me perdi un poco. Tambien estaria bueno ver un repositorio con un ejemplo mas completo que involucre varias entidades del dominio para ver como crece esta arquitectura con un ejemplo mas real. Tienes algun repo donde pueda ver algo asi? Muchas gracias!

[@victorcomo4952]

Excelente video!!! Saludos desde Argentina

[@luisurrea4618]

muy bien explicado me ayudo un monton, muchas gracias.

[@DavidSoles]

Excelente explicación. Muchas gracias. Me gustaria saber tu opinión con respecto a estructurar la aplicación en torno a la funcionalidad, en lugar del rol que juega cada clase (controller, service, repository). Al utilizar una estructura en base a funciones los tres archivos básicos (controller, service, repository) quedarian dentro de un mismo paquete. Hago la pregunta porque dicha discusión fue introducida por Josh Long que es Developer Advocate de Spring.

[@portalo3686]

Grandisimo video!!

[@rmendozareyes1594]

Excelente aporte, tengo mucho por aprender para poder ser un arquitecto de soluciones

[@CamiloCastroEscorcia]

Excelente video. Muy buena explicación.

[@EMILIOJOSEV]

Muchas gracias por compartir tan buen contenido de valor!

[@martineduardovega724]

muy bueno este video, gracias por compartir este tema.

[@yas-code]

Exelente, buen trabajo esta super claro

[@ilichbetancourtrangel41]

Que genial!! Cuanto hay para aprender 🙌🙌💪💪

[@cristianmanuel-d5d]

Muchas gracias por la explicacion!

[@saksahgx4011]

Explicación magistral :D

[@eduardoeljaiekrodriguez3492]

Excelente explicación. Seria genial, si en proximos videos usas el modo presentación de Intellij, para poder visualizar el codigo con mayor claridad.

[@gonzalooviedo5435]

El codigo lo vi perfecto, raro, bueno, en una tv de 43"

[@el_yisusT]

Grande tu explicación. Muchas gracias. Ahora bien, mi opinion sobre clean architecture ya es otra cosa, porque tantas divisiones de capas es de todo menos limpia.

[@horasalva1194]

Hola! La logica de negocios de la clase Account, no deberia estar fuera de esa capa? en los puertos o los adaptodres? Parece se mezcla el dominio con la logica de negocios

[@michelYo]

Hola Yoandy, este libro “ arquitectura limpia” está orientado a un lenguaje de programación en particular?

[@SACAViXTech]

Hola Michel, no, no está orientado a nada particular, es agnostico, totalmente teoría y pocos ejemplos pero genéricos, casi pseudo code

[@pablollanos3539]

Muy buena explicación

[@carva33]

Mil gracias!!, Excelente video, sería interesante hacerlo tmb en Python, Rust y Gonlang.

[@jazzyniko]

Estoy con Laravel ahora y no viene mal entender lo de las arquitecturas. Springboot es FULA pa un principiante como yo pero espero avanzá y dar el salto a java en un futuro cercano.

[@CaloPocha]

Excelente explicación, sería bueno una implementación real, de un caso de uso, como almacenes que es algo muy sencillo. Bendiciones!!!

[@alejandrosantana4259]

Excelente explicacion 👍

[@alejandro_930fbcfc14]

Me hace un poco de ruido el @Transactional en el service dado que estarías "ensuciando" un poco la lógica de negocio con algo propio de la persistencia, es más, de no poder concretar la transacción por ejemplo un campo not null en la base que lo queremos insertar con null, lanzaría una excepción propia de la capa de persistencia y el catch de esa exception donde lo pondrías? en el controller?

[@ospina5367]

Gracias por la explicacion. Donde puedo encontrar los slides de la presentacion?

[@danielburbano1442]

Bueno video, una recomendación no se debería incluir lombok en el dominio dado que estaríamos agregando la dependencia a esta librería.

[@juliomejia9824]

Hola, recién descubro el canal, tienes por ahí la reseña de tu libro? Quiero evaluar ser mecenas. Excelente contenido.

[@samsagaz_akas]

en application, transactional al ser externo, no deberiamos meterla en los detalles (adapters) ?

[@FacundoSebastianCordoba]

buenas tardes andy, saludos de argentina . hace poco te sigo y me gustaria mejorar mi diseño de aplicaciones y vi que recomendaste 3 libros 1_clean code 2_el programador pragmatico 3_ arquitectura limpia mis preguntas serian: ¿ por cual recomiendas empezar? y ¿ donde se los puede conseguir?. Desde ya muchas gracias.

[@rafaeltorresyera2340]

Hola! El libro se pudiera compartir me gustaria poder leerlo. Excelente video.

[@yoandyperez8825]

Hola Rafael, lo compré físico, en digital esta disponible en kindle y en otras webs.

[@ramfredy]

Excelente video

[@continue5429]

Genial, gracias crack.

[@juancamiloarenasflorez8841]

Gracias

[@davidquimbiulco248]

Super!!! el video

[@compartelo007]

Entiendo que por similitud cuando usas la clase mapper parar convertir objetos del dominio a la entidad y viceversa. Es como cuando usamos DTOs to Entity y viveversa. Saludos

[@joshuaatencia4629]

muy bueno tu video, aveces se me complica implementar esta arquitectura ya que lo implementan de distinta formas y nose cual es la mas fiel jajjaja

[@JuanCHB_88]

Tambien una buena practica tambien para hacer mucho mas facil todo el tema de las dependencias del proyecto son utilizar gradle, Maven con ese archivo pom es una locura utilicen gradle por Dios benditooo

[@SACAViXTech]

Hola, me gustaría saber cuales son las ventajas de Gradle sobre Maven.

[@felipemedinasalvatierra2094]

Que nuevo traen estas arquitecturas agiles? A caso no es la arquitectura N Capas + OCP(Bertran) y que está estrechamente relacionado con LSP(Barbara Liskov). A los que R.Martin los juntó(le llamó DIP).

[@SACAViXTech]

Un nombre nuevo solamente 😃, palabras de moda solamente 🤣

[@felipemedinasalvatierra2094]

@@SACAViXTech ah ok y como lo presentan como cosas suyas, hay q dale meritos y mencionarlos a los ancestros😆

[@miguelpina7040]

¿Tienes algun video de Spring Boot desde cero? Saludos desde Cuba.

[@tuttodev]

Hay muchas formas de implementar arquitectura, limpia, de hecho donde trabajo la implementamos de una forma totalmente diferente a como yo estoy acostumbrado a implementarla, ¿es malo? PARA NADA, cada empresa puede sacar cosas de cada abstracción de las arquitecturas limpias, lo importante es respetar el porqué de la arquitectura limpia y de eso derivan sus reglas. Si quieren ver otro proyecto con arquitectura limpia, en mi canal podrán ver otras forma de aplicarla como complemento a este video. Un saludo y muchas gracias por compartir tu conocimiento.

[@TheRamseven]

Buen video, como apareces en Linkedin?

[@arielchacon8776]

Hola, mi duda es acerca de devolver un DTO en el Adaptador en lugar del Domain Object, ¿Quién se encarga de hacer ese mapeo, la capa de Aplicación o la Infraestructura?

[@jamilmendez492]

Buenísimo

[@phybriso]

Uff, está compleja pero la explicación es buena, gracias

[@EduardoAntonioGonzalezMora-o9b]

pregunta tienes alguna idea de quien es yasiel_ trabajo un tiempo en la uci_

[@Thematrixhackyou]

Fantastico tutorial, pero no entiendo cual es la diferencia exacta entre un InputPort y un OutputPort

[@fabianrr]

Duro 👌

[@Haibrayn42]

La restricción del caso de uso dice GraterThan, pero parece que se comporta como EqualOrGraterThan

[@ericidrogo]

excelente

[@juanmanuellopez6222]

El tema es que aplicar este tipo de arquitectura en algo que solo sera un CRUD lo veo como sobre diseñar, si queremos que algo sea mas abstracto ya sea por accioens CQRS en caso de dominio DDD, lo que no me queda claro que deberia existir el espacio de trabajo en el cual no tenga asociado en elframeworks ya per estariamos realizando el acoplamiento :S

[@prezdev]

Cabe mencionar que la arquitectura hexagonal no es una variante de arquitectura limpia. La arquitectura hexagonal es del 2008, 4 años antes que arquitectura limpia. De hecho, la arquitectura limpia es una variante de la arquitectura hexagonal.

[@CristianRodriguez_baruchneo]

Hola muy bueno el video y muy clara la explicación en especial la implementación dela arq hex, tengo una duda s respecto a os port y los adaptadores si la persitencia tiene n clases como acoplo toda esta cantidad de entidades para la persistencia, esto se puede volver muy grande no en especial por la cantidad de clases por entidad

[@Piczzi]

¿Cuál es el tema que estás usando en tu IDE?

[@rickhunter8216]

DARK

[@faqcodes]

El tema de Clean Architecture esta muy bien explicado, gracias!. Sin embargo, la implementación no me parece correcta. En la capa de Application no debería implementar nada desde la interface de los Ports (principio de Inversión de Dependencia). También veo que la anotación @UseCase depende del framework Spring Boot. Este tipo de dependencias es lo que trata de evitar las Clean Architecture. Saludos!

[@pauolive7239]

¿Entonces tu personalmente intentas evitar siempre la arquitectura en capas en la actualidad?

[@SACAViXTech]

No, siempre intento conocer los límites para decidir que usar. Proyectos pequeños no uso esto, proyectos grandes lo uso. Pero el tamaño es relativo y en ocasiones me equivoco. 🤪

[@horasalva1194]

No veo que estes aislando la capa spring, si en en el controller usas la anotacion RestController, ahi no veo el sentido de la WebAdapter.

[@adryanynfantevalero8310]

Alguien tiene el pdf del libro en español??

[@HighOctaneNews570]

Casi me explota la cabeza xd

[@emanuelvallejo5705]

Primero :v

[@edanla]

soy mas del "private final" e inyección a través del constructor 🤓, en vez del Autowired! 🤢

[@SACAViXTech]

Yo igual ehhh, gracias por comentar, capaz se me fue alguna inyección por atributos.

[@mateobro2540]

Por qué es mejor la inyección a través de constructor?

[@edanla]

@@mateobro2540 Es explicita, permites que el IDE te ayude a evitar referencias circulares. Adicionalmente cuando vas a trabajar en los tests unitarios, conoces de forma explicita las dependencias de tu objeto, te evitas cosas raras como tener que usar reflection para inyectar dependencias.

[@mateobro2540]

@@edanla gracias por la info!

[@untalsanders]

@@mateobro2540 en Spring cuando se levanta el contexto de la aplicación, internamente Spring ve los constructores de las clases y todo los parámetros que pases por constructor serán puesto en el contenedor como un Singleton. @Autowired es una manera explícita de decirle a Spring que los use como dependencias de ese bean en particular cuando cree la instancia. Sin embargo no necesitas explicitar el @Autowird a menos que tengas más de un constructor, ahí necesitas decirle a Spring que aquél que esté anotado con @Autowired será que el que use para poner en el contenedor. Por otro lado como dice @Edgar Lora Ariza te facilita la vida a la hora de testear, además que si cambias de framework un día, no se, de repente te da por usar Quarkus, bueno en ese caso al tener las dependencias de tu bean (@Controller, @Services o en general @Component) mediante constructor, podrás usar las anotaciones correspondientes o la estrategia de inyección de dependencia del framework que uses.

[@aladroangel-tt9wm]

Hola soy el hijo de tu amigo eve

[@coronelpimienta1995]

ammm la arquitectura de 3 capas ya practicamente es obsoleta.

[@angelhermozo]

Muchos proyectos llegan con subre arquitectura no es muy bueno la verdad todo exceso es muy malo

[@ConvierteteAJesúsAhora]

Dijo una palabra fea, y yo estaba comiendo.

[@Batuzai25]

Excelente master, pero este video me causa duda, kzbin.info/www/bejne/gHXCi39pd9OUpck, puede responde al repecto de como ubican lo puertos

[@manuel__Youtube]

que rapido hablamos los cubanos

[@brandpcalderon5343]

Jaja, toda la arquitectura de software, los patrones de diseño y clean code, se basa en los principios SOLID, así de sencillo

[@tictac7499]

Es mala opción el estudio de estos temas utilizando frameworks...no es lo mismo entender que saber...☝️😎