Arquitectura Limpia: Un ejemplo práctico con Spring Boot
ฝัง
- เผยแพร่เมื่อ 15 ก.ย. 2024
- La arquitectura limpia es un concepto que nos invita a desarrollar aplicaciones que cumplan con el objetivo real de la "arquitectura de software". Esta serie de principios o practicas a tener en cuenta fue popularizada por Uncle Bob (Robert C. Martin) en el libro "Clean Architecture", en este video de aproximadamente 40 min vas a aprender sobre este tema y veremos un ejemplo práctico.
✅ Aprende más en nuestro blog: sacavix.com/
✅ Apoya nuestro trabajo: paypal.me/yoan... (Te daremos un regalito)
✅ Apóyanos en Patreon: / sacavix_tech
(Con tu apoyo en Patreon accedes a ventajas exclusivas como directos, preguntas y respuestas en el chat, respuestas a tus dudas y acceso a nuestro libro "Patrones para la implementación de una arquitectura basada en microservicios".
✅ Accede a la Academia SACAViX (beta), academia.sacav...
Aprenderás al ver este video:
- Los problemas de la arquitectura en capas.
- Los principios SOLID y su relación con la arquitectura limpia.
- Que es la arquitectura limpia.
- Arquitectura hexagonal como ejemplo de arquitectura limpia.
- Ejemplo practico de arquitectura limpia (hexagonal) en Spring Boot.
- Cuando conviene usar arquitectura limpia.
Accede al código fuente acá: github.com/yoa...
#arquitectura #cleanarchitecture #hexagonal #unclebob #springboot
que es la arquitectura limpia
ejemplo arquitectura limpia
ejemplo arquitectura limpia spring boot
ejemplo arquitectura hexagonal spring boot
Llevo un mes buscando un vídeo de este en español y sale este crack
Este canal es excelente!! No me hice fan, me hice adicto jaja... Ofrece Data de mucho nivel y muy valiosa!!!
Siempre has sido un crack, saludos hermano !!!
más claro ni el agua!!! excelente charla
Excelente aporte. Muchas gracias! 😎
Éste man es un duro, va conciso y al grano sin tanto rodeo. Excelentes videos!!!
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.
Me parece perfecta la explicación. Ya había visto otros videos pero algo se quedaba en el tintero!
Gracias!!
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.
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.
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.
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
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.
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.
@@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
@@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.
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
Excelente video!!! Saludos desde Argentina
voy en el minuto 18. Muy buena explicación. Muchas gracias por el contenido!
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?
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.
Muy bueno el video, me sirvió mucho para terminar de entender de manera sencilla los conceptos de arquitectura limpia, 👍
Explicación magistral :D
Simple, concreto y muy útil, muchas gracias, excelente video
Que genial!! Cuanto hay para aprender 🙌🙌💪💪
excelente explicación y ejemplo, muchas gracias!!!
Te ganaste otro suscriptor tmb, me caiste muy bien, se nota el esfuerzo que haces por transmitir y lo haces de forma clara y genuina sin caer en el alardeo y egocentrismo como en se en algunos programadores.
Mil gracias por este vídeo. La calidad del contenido de tu canal es increible!
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!!
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!
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.
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?
@@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);
}
}
Elimina mis respuestas, creo que no le gustó lo que comente 🥺
Super!!! el video
Gracias
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?
Duro 👌
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
Excelente. Muchas gracias por compartir información tan valiosa
Excelente aporte, tengo mucho por aprender para poder ser un arquitecto de soluciones
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.
Muchas gracias por compartir tan buen contenido de valor!
Genial, gracias crack.
Excelente video. Muy buena explicación.
muy bien explicado me ayudo un monton, muchas gracias.
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!
muy bueno este video, gracias por compartir este tema.
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.
Impresionante, no conocía el principio, me lo quedo , gracias por compartir 👍
Completamente de acuerdo, asi te proteges de los comportamientos indeseados, como que te pasen por parámetro un valor negativo.
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.
Mil gracias!!, Excelente video, sería interesante hacerlo tmb en Python, Rust y Gonlang.
Exelente, buen trabajo esta super claro
Excelente explicación, sería bueno una implementación real, de un caso de uso, como almacenes que es algo muy sencillo. Bendiciones!!!
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.
Muy buena explicación
Muchas gracias por la explicacion!
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
Excelente video
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.
Excelente explicacion 👍
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
Buenísimo
Excelente explicación. Seria genial, si en proximos videos usas el modo presentación de Intellij, para poder visualizar el codigo con mayor claridad.
El codigo lo vi perfecto, raro, bueno, en una tv de 43"
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.
en application, transactional al ser externo, no deberiamos meterla en los detalles (adapters) ?
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.
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.
Uff, está compleja pero la explicación es buena, gracias
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
Fantastico tutorial, pero no entiendo cual es la diferencia exacta entre un InputPort y un OutputPort
excelente
Hola, recién descubro el canal, tienes por ahí la reseña de tu libro? Quiero evaluar ser mecenas. Excelente contenido.
¿Tienes algun video de Spring Boot desde cero? Saludos desde Cuba.
Gracias por la explicacion. Donde puedo encontrar los slides de la presentacion?
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
Hola Yoandy, este libro “ arquitectura limpia” está orientado a un lenguaje de programación en particular?
Hola Michel, no, no está orientado a nada particular, es agnostico, totalmente teoría y pocos ejemplos pero genéricos, casi pseudo code
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?
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.
Buen video, como apareces en Linkedin?
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).
Un nombre nuevo solamente 😃, palabras de moda solamente 🤣
@@SACAViXTech ah ok y como lo presentan como cosas suyas, hay q dale meritos y mencionarlos a los ancestros😆
Hola! El libro se pudiera compartir me gustaria poder leerlo. Excelente video.
Hola Rafael, lo compré físico, en digital esta disponible en kindle y en otras webs.
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!
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.
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
Alguien tiene el pdf del libro en español??
¿Cuál es el tema que estás usando en tu IDE?
DARK
¿Entonces tu personalmente intentas evitar siempre la arquitectura en capas en la actualidad?
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. 🤪
Casi me explota la cabeza xd
Primero :v
ammm la arquitectura de 3 capas ya practicamente es obsoleta.
soy mas del "private final" e inyección a través del constructor 🤓, en vez del Autowired! 🤢
Yo igual ehhh, gracias por comentar, capaz se me fue alguna inyección por atributos.
Por qué es mejor la inyección a través de constructor?
@@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.
@@edanla gracias por la info!
@@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.
Excelente master, pero este video me causa duda, th-cam.com/video/JD_ZL3Bnaog/w-d-xo.html, puede responde al repecto de como ubican lo puertos
Muchos proyectos llegan con subre arquitectura no es muy bueno la verdad todo exceso es muy malo
Es mala opción el estudio de estos temas utilizando frameworks...no es lo mismo entender que saber...☝️😎
Hola soy el hijo de tu amigo eve
que rapido hablamos los cubanos
Jaja, toda la arquitectura de software, los patrones de diseño y clean code, se basa en los principios SOLID, así de sencillo
El tio bab hacer arquitecturas... que son lentas!
Mucho rollo y en farfullo medio yanki. Es incomprensible.
La Entity ORM, deberia ir en frameworks y driver o infrastructure.
Falta el Presenter, InputData, OutputData, ViewModel, InputBoundary, OutputBoundary(Estos ultimos si son los puertos), el Objecto Modesto o humlde no estan presentes aqui tampoco
Los puertos no son esas interfaces, claramente en el libro en la figura 22.2 del capitulo 22 nos dice que el InputBoundary es la entrada al interactor, el interactor utiliza las entities asi como la base de datos, una vez el interactor termina reune la informacion y crea un OutputData que se pasa a travez del pueto de salida OutputBoundary que sera utilizado por el Presenter, el Presenter vuelve a empaquetar en un ViewModel y finalmente le entraga a la vista.
Lo que veo aqui es un intento de comprender el libro y aplicar la Arquitectura heaxgonal 😁
Revisar esto. i.stack.imgur.com/kcQ7t.png