¿Son tus controllers SOLID? | Clean Architecture
ฝัง
- เผยแพร่เมื่อ 8 ก.พ. 2025
- En este video hablamos de los principios SOLID aplicados en la arquitectura hexagonal, enfocandonos sobretodo en el principio de responsabilidad unica (SRP), viendo como lo podemos aplicar a casos de uso y tambien a controladores HTTP.
🔔 No te olvides de suscribirte y activar la campanita
► www.youtube.co...
🌍 Puedes encontrarme en: alberthernande...
🐦 Twitter: / alberthernandev
Os dejo aquí el link al proyecto en GitHub :)
github.com/AlbertHernandez/controllers-single-responsibility-principle
Gracias por compartirnos tu conocimiento, eres un crack!
desde mi punto de vista tienes toda la razón con el tema del controller. en algun punto alguien lo implento de esa forma y ya sabes es copiar y pegar, pero no nos damos cuenta que eso en proyectos grandes puede ser un caos. excelente Albet !
Saludos. Tus videos son muy buenos, explicas de forma clara. Gracias por compartir tu conocimiento y experiencia
Hehe encontraste el video oculto 👀 Nada es un placer compartir y ver como sirve todo lo que comparto, un saludo 😁
Mirando todos tus videos en orden cronólogico, excelente contenido. Esperando el curso de pago 🙋♂
Hahaha muchas gracias!! A veces cuando veo los vídeos del principio… uff muchas cosas habían que mejorar (y muchas otras que aun tengo) pero espero que te hayan gustado :D
Explicaciones objetivas gracias !
Se me hace muy similar al patron command-query-separation(cqs). Muy buen video!
Buenas! Si, todo esto encaja muy bien aplicando luego CQRS, es una buena combinación :D
Me gustaria que investigases una cosa que puede que te guste, se llama Clean Architecture + Vertical Slicing. Solo si te parece buena idea claro
Porcierto, ya van varias veces que me ayudas a entender las cosas en comparación a otros videos mis 10/10 Sigue asi y mucho animo que vas por buen camino
Buenas! Si, conozco lo de vertical slicing, me gusta bastante como combina con la clean architecture, el mayor problema suele ser luego la típica carpeta common o shared donde se suele tender a poner muchas cosas, aunque con un poco de cuidado puede quedar algo bastante bien
Me alegro que te vayan sirviendo los videos, espero poder seguir aportando más a la comunidad y así que todos vayamos aprendiendo y mejorando :)
Excelente. Me gustaria ver como resuelve clean architectura ejemplos mas complejos por ejemplo con relaciones de tablas, con mas reglas de negocio
Si, cuando una app ya empieza a escalar las cosas se vuelven las interesantes, al final es aplicar lo mismo pero a distintos niveles, tengo intención de crear una app mas compleja donde se vea mejor como aplicar todo esto a complejos más complejos :)
Buenas Albert, hace poco encontré tu canal y he visto unos cuantos videos tuyos, y la verdad me encanto, no se si podrías hacer un curso/taller para el desarrollo de una red social, o algo, al menos con las bases para entender y aplicar tdd, arquitectura hexagonal etc, de mi parte no hay problema si haces el curso/taller de pago, ya que la calidad de tus videos lo valen, espero y pronto ver ese curso/taller, ya sea el udemy o donde tu lo hagas, saludos desde MX !
Buenas Eduardo! Llevo un tiempo pensando en hacer algún curso más completo donde veamos cómo hacer una app más compleja de manera iterativa. Por ahora, todo lo que haga lo quiero hacer de manera gratuita 😁. Lo que ya tengo dudas es si hacerlo usando frameworks como NestJS o sin frameworks para que se vea todo mejor. ¿Qué te gustaría ver? (Así voy recogiendo feedback de las cosas a hacer)
@@AlbertHernandez Gracias por responder Albert, pienso que seria mejor en un inicio sin framework, para que veamos como ir haciendo un proyecto desde 0, y cuando toque usar framework, saber que se puede modificar o que cosas ya estan bien, saludos !
Si, me gusta, quizás podamos empezar por uno sin framework y luego uno con framework, así se podrán ver también las diferencias y los pros/cons de usar frameworks
@@AlbertHernandez Muy bien, estaré al pendiente para cuando salga el video, saludos !
Me gusta este tipo de material , clean , solid , hexagonal etc etc , te dejo like y sub , me veré los videos que tienes sobre estos temas en lo que subes nuevo material , gracias
Me alegra que te guste :)
Amigo, podrias hablar un poco por favor de como mantener las exceptions, errors etc SOLIDos para nuestros servicios rest, asi mismo el tema de loggin, como no ensuciar el codigo y mantener una buen exception handling?,
Buenas! Sí, claro. Tomo nota para futuros videos, gracias por la sugerencia!
Muy buen video. Explicas muy bien. Y al respecto de los controladores tienes razon. Nosotros hacemos test de controladores que tiene 6 u 8 methods crud. La forma que tu comentas permite un mejor test y encontralos de forma sencilla. El PUT que comentas es por permitir hacer un UPSERT de usuarios?
Gracias! Me alegro de que te haya gustado :) Sí, cuando una aplicación ya comienza a crecer y ya se tienen varios métodos, como comentas, es ahí cuando se ve la ventaja de tenerlos separados. El uso de PUT en lugar de POST es para forzar que sean los clientes quienes generen los identificadores de los recursos, ya que esto nos proporciona una serie de ventajas (también algunos inconvenientes, no te voy a engañar, pero al final todo son trade-offs) tanto para los clientes que consumen la API como para los que la construyen. Hablaré de todo esto más en un futuro, pero por si quieres echarle un vistazo, te dejo unos artículos donde se explica todo esto:
- tkg.codes/client-side-resource-ids/
- www.techyourchance.com/client-generated-ids-vs-server-generated-ids/
Hola bro, ayer conocí tu canal y me parece que esta 9/10. Me gusta tu contenido.
Solo un consejo y es que me cuesta muchas veces entender lo que dices, siento que hablas muy despacio, quizas sea el micro con el que grabas, pero por todo lo demas esta muy bueno el contenido.
Saludos desde Colombia.
muchos éxitos.
Hola! Me alegro que te guste el contenido, gracias por el feedback, a veces me da temor que si voy demasiado rápido no se entiendan bien los conceptos pero lo tendré en cuenta para futuros videos, un saludo!
Para mí que vayas lento está bien. Siempre a puedes aumentar la velocidad desde la configuración del vídeo.
@@AlbertHernandez Igual encuentro que es buena velocidad, no todo el mundo va más rápido. En mi caso le pongo un poco más de velocidad con las herramientas de youtube.
Cuando decía despacio me refería a el tono de voz, no a la velocidad.
Siento que debe hablar un poco mas fuerte.
Hola, muchas gracias por el contenido, en verdad que es de mucha calidad!! También quisiera preguntarte, podrías compartir este repositorio como has hecho con otros? me ayudaría a la hora de pulir lo que estás enseñándonos, por fa
Ups, pensaba que lo había dejado fijado, ya lo he puesto, gracias por avisar :)
github.com/AlbertHernandez/controllers-single-responsibility-principle
Hola! Exelente video, me lo guarde para tenerlo más adelante, pero me genero muchas dudas. Estoy iniciando con las arquitecturas limpias y me hace mucho ruido las clases con un solo método. Para estos casos se podría utilizar una función en vez de una clase? Es decir, si cada caso de uso es una funcionalidad con una responsabilidad única y específica, para que hacer una clase y no una función? Luego sería solo invocar el caso de uso deseado, lo que tambien seria ahorrativo, ya que no se debe instanciar un nuevo elemento.
Buenas! Eso depende más bien de cómo queramos trabajar, si con un enfoque más orientado a objetos con clases o con otro enfoque más funcional en el que todo sean funciones. No hay ninguno mejor que otro, simplemente son distintas. Yo por ejemplo, suelo utilizar clases por el tema de la estandarización de cómo inyectar dependencias, contenedores de dependencias, librerías que hacen mocks automáticamente de dichas clases y demás... Con ambos estilos se puede conseguir el principio de responsabilidad única, así que no habría ningún problema. Un saludo!
@@AlbertHernandez Muchas gracias!!!
A ti 😁
uy buen material! que herramienta estas usando para dibujar los diagramas? gracias!!
Buenas! Pues en este caso estaba usando excalidraw :)
Gracias bro, buen video, como mantendrían los controllers con SOLID, cuando para un mismo bounded context tenemos varios metodos HTTP, ejemplo para el user-get-controller.ts. tambien podríamos tener otro get que sea para obtener usuarios con diferentes filtros, si bien diríamos implementamos specification, pero si no lo tendríamos, como lo manejarías?, así mismo puede aplicar para otros métodos.. los nombrarías como el use case?
¡Buenas! Pues creo que tener un mismo bounded context no implica que todos los casos de uso deban estar ni en la misma clase ni en el mismo controller.
Como comentas, si para los usuarios tenemos varios filtros, lo mejor sería implementarlo usando el patrón criteria, ya que esto nos permitiría tener un único endpoint donde le pasamos una serie de filtros y le permitiría al cliente construir los filtros que desee sin la necesidad de tener endpoints específicos para cada cosa.
En el caso de que no queramos implementar este patrón por ciertas circunstancias, como tener varias acciones para obtener un usuario por su email, obtener usuarios por edad o cualquier otra cosa, sí, tendría distintos casos de uso y distintos controllers. Aunque, como te comento, lo mejor desde mi punto de vista sería implementar un Criteria, ya que nos ahorraríamos todo esto y lo tendríamos solucionado en un único método.
Espero que te haya ayudado. Un saludo!
El primero de los principios SOLID se refiere a una única gestión. No a una única tarea. Mi crítica es con respecto al controlador. El resto está perfecto para mi.
Coincido, se suele malentender mucho la S de SOLID 😅
Muy buen video 👏👏, ahora me he quedado con la duda de porque usas put en lugar de post.... 🤔
Lo más probable es que veamos esto en futuros videos, pero para que no te quedes con la duda, la diferencia entre un PUT y un POST al crear un recurso es principalmente el ID. En el POST, es el backend quien lo genera y en el PUT, es el cliente. Teniendo en cuenta esto, ya se puede entrar en discusión acerca de quién debería generar los identificadores, si los servicios o los clientes. Hay varios artículos que hablan de estos dos enfoques, cada uno con sus pros y cons. Te dejo algunos a continuación por si quieres echarles un vistazo. Un saludo!
- tkg.codes/client-side-resource-ids/
- www.techyourchance.com/client-generated-ids-vs-server-generated-ids/
@@AlbertHernandez Muchas gracias por responderme. Les echaré un vistazo🤩
Es un placer :)
Crack 😁
Panita que piensas de Koa?
Hola! Pues creo que está muy bien. Es una buena alternativa a Express. En mi trabajo es lo que usamos y en algunos proyectos personales que tengo también lo uso y no tengo queja. Aunque quiero meterme en Fastify, ya que se está hablando muy bien de él y dicen que es bastante más eficiente que Express
Que plataforma utilizo para realizar el diagrama?
Excalidraw :)
¿Porque siempre confunden el principio de responsabilidad única con tener una clase con 1 método run/excecute/invoke? los handlers tiene sentido en varios casos y está bien, es cuestión de gustos! pero tener un servicio que cumpla una responsabilidad única, no implica tener una clase con un solo método. De todas formas es una linda arquitectura la que presentas. Saludos
Sí, se suele confundir mucho. En el libro de Clean Architecture lo redefinen para que no haya esta confusión: "Un módulo deberá ser responsable de un, y solo un, actor". Coincido en que esto no implica que una clase tenga solo un método, por ejemplo, a nivel de repository, de SDK... pero a nivel de controller ya tengo dudas. Supongo que es como todo, depende del contexto, y como dices, también un poco a nivel de gustos. Lo que más me gusta de tenerlo separado es cómo quedan luego las cajas que comento. No se unen las flechas hasta llegar a niveles bastante internos, por lo que el código de distintas acciones, que es probable que también dependan de actores distintos, será independiente en más puntos y es más probable que se respete más este principio. Un saludo!
Quizas tu lo confundes, y crees que lo que propuso @Albert Hernandez en este video esta mal.
Pero no es así, quizás de momento lo vez simple, y un solo método, pero piensa que mas puede hacer tu controller, como el exception handling, validar la request. Básicamente varias la adaptación de lo que necesita tu cliente y el caso de uso que vas a ejecutar, no tienes porque tener un solo método, Quizás uno publico si. pero otros privados. ademas de que el lo acota al verbo, podemos tener muchos GETS, como También Muchos POST, ahora bien, quizás elegiría tenerlo como el caso de uso quizás un POSTCreateUserController, POSTFindAllUserById etc.
De esa forma voy a ubicar todo rápido cada vez que suceda un error, o cada vez que alguien me pida un cambio.
Buenas!
Apoyo esa arquitectura, pero hasta que punto?
En un proyecto trabajamos de la siguiente manera "controlador, mánager, repositorio" y separamos de la siguiente manera por entidad:
1 y 1 mánager para el CRUD básico y controladores + mánager para los nuevos casos de uso. Pero todo en un repositorio.
¿Hasta que punto seguir separando y teniendo más archivos si el proyecto sigue escalando?
Buenas! Pues ese es el punto, si tienes un proyecto sencillo donde un controlador y un manager tengan unos pocos métodos, quizás no se note mucho el beneficio. Pero conforme esos métodos se vuelvan más grandes y tus aplicaciones crezcan, con más desarrolladores involucrados, es cuando se ve más la ventaja de tener todo esto separado.
Te pongo un ejemplo, un desarrollador trabaja en un proyecto donde hay un controlador con N métodos y un manager con N métodos. Si quiere añadir una nueva funcionalidad que afecte tanto al controlador como al manager, lo más probable es que le cueste más, por ejemplo, en el test, porque debería saber cómo instanciar un manager o un controller con los otros casos de uso y lógica que a él no le interesan. Sin embargo, si solo tuviera que crear un nuevo controller y su caso de uso, no tendría estos problemas. Crea sus clases, inyecta las dependencias que necesita y listo.
Al final, todo se trata de encontrar un equilibrio y de lo que mejor se adapte a las necesidades de los proyectos. Dependiendo del contexto, puede que nos merezca más o menos la pena seguir separando
En general prefiero crear un crud controller que extiendo para cada tipo ya que mucha de la lógica se repite
Dependiendo del caso, puede venir bien, pero hay que tener cuidado con la herencia, ya que puede suceder que tengas ciertos casos en unos controladores que luego no se apliquen a otros, lo cual te limitaría más