Hace un par de meses realicé un proyecto donde apliqué la clean y me doy cuenta que estuvo relativamente bien implementada, lo unico que no implementé fueron los dtos tanto de aplication como de infraestructure, en su lugar use meras intefaces lo cual sigue siendo muy parecido, estoy contento con la aplicacion implementada. Gracias por este contenido ❤
Fantástico 👏, la primera vez que se implementa siempre surgen dudas, y sobre todo si es en un framework que cuesta el poder separar las cosas y no acoplarse. Yo, por ejemplo, sí suelo separar los DTOs de aplicación y de infra por dolores que he sufrido al no hacerlo, ya que, por ejemplo, la API que estás exponiendo puede ser en snake_case, y luego tú siempre quieres trabajar con camelCase, que es el estándar de NodeJS. Entonces, sería en ese punto donde podríamos hacer toda esa conversión. También serían esos DTOs donde pondríamos cosas como la documentación de Swagger de la API, y tener eso en la capa de aplicación no me termina
Hola Albert! Un poco tarde pero por aquí siempre, tú sabes jaja. Felicidades, está de lujo el video. Veo que en tu repositorio incluyes ya temas de testing que cubren bastante, crees poder traernos en algún momento testing para este proyecto? Estaría de lujo!
Hey! Gracias por siempre estar apoyando hehe, pues si, tengo pensado traer cosas de testing en futuros videos pero voy poco a poco que no me da para todo haha pero lo traeré 😁
Felicidades por el video Albert. Hice un proyecto bastante parecido al tuyo incluyendo eventos de dominio, testing, base de datos, value objects, etc. Pronto lo subiré a github y te paso el link de medium por si le quieres echar un vistazo :) Lo único que me chirría un poco del video es la parte de tener que forzar a tu dominio a crear clases abstractas en lugar de interfaces para evitar el uso del famoso "@Inject('Interfaz')" de inversify en cada constructor. Creo que es algo muy particular del framework nest js y que si mañana cambiáramos de framework quizás no tendría sentido y si utilizar interfaces, no sé, es una reflexión que quería compartir contigo. Gracias por compartir el contenido
Gracias! Si cuando lo tengas pasa link y le daré un vistazo, gracias por compartirlo también :) Respecto a lo de la clase abstracta si, coincido, al final es el trade-off que estoy pagando por el hecho de no poner el Inject del framework en el dominio, también al usar clases abstractas puedo usar ciertos helpers de jest para generar mocks automáticamente que me vienen bien así que bueno, es un precio que no me sabe tan mal pagar hehe Un saludo!
Buenas! Pues justo todo el docker que esta en este proyecto si que esta hecho en un video donde explico paso por paso como se crea y se ve en mas detalle hehe, te lo dejo a continuación por si quieres darle un vistazillo, y cualquier feedback o cosa que veas que no queda clara me dices y asi intento hablar de ello en futuros videos :D th-cam.com/video/J4J2wgZ8yWE/w-d-xo.html
Buen video, pero me hubiese gustado ver la diferencia entre un caso de uso y un servicio de dominio o para que sueles utilizar los servicios de dominio y poder haber visto un ejemplo
uff gracias por la explicacion... y gracias a yt por recomendarme el canal jajajajjaajja... hace rato que buscaba algo asi con nestjs(amo el framework ojala perdure y logre afianzarse aun mas) y no encontre casi nada... y con eso me aparecieron muchas dudas... si hacerla de 0 o respetar la que ofrece nest de manera predefinida etc... saludos desde Argentina... vi que tienes varios mas de nestjs voy a ponerme al dia jejejje
Un placer! Qué bueno que youtube comience a recomendar mas el canal 🚀 Dale caña, hay varios videos de NestJS en el canal y luego tambien mas generales de Node, que tambien se pueden aplicar al framework hehe Lo de respetar la manera de NestJS depende mucho lo que quieras conseguir, puedes desde ir a full con el framework, hasta aislarlo del todo, y luego siempre tienes el punto intermedio que también suele ser muy buena opción hehe
Albert, espero estes bien. Regreso de un buen tiempo luego de haber visto y aplicado el video (que por cierto, gracias, está muy valioso como todos) y me surgió una duda cuando mencionaste el tema de crear un decorador Transactional, cómo sería una implementación de transacciones en arquitectura hexagonal? Podrías de pronto hablar de eso en un video? Gracias nuevamente!
Muy buenas Juan! Pues para implementarlo hay varias opciones, una de ellas es en la capa de infrastructure crearte tu decorador transactional, los tipicos de Typescript y ahi que sea donde creas la transaccion y cuando ha acabado que haga el commit y en caso de que falle el rollback, he encontrado esta libreria que ya da una posible implementacion de este transactional por si le quieres dar un vistazo: www.npmjs.com/package/typeorm-transactional De todas formas, lo mas probable que en un futuro video hable de todo esto y como lo podemos implementar nosotros mismos si Un saludo
Excelente video! Bien explicado. He implementado esta manera de hacer de hacer un proyecto, pero simore tengo unas de como hacer los casos de uso cuando se trabaja con relationes; como por ejemplo la relation one to many o many to many. Me gustaria una explicación de eso
Gracias 😁 Me apunto eso de las relaciones para traerlo en un próximo video. Si te sirve para ir avanzando la idea es que todo ese tema de relaciones lo puedes ir consiguiendo añadiendo los ids en las entidades que se relacionan, o en en caso de que siempre siempre vaya junto, directamente puedes poner uno dentro de otro, pero hay que tener cuidado luego con esto ya que la idea principal es tener entidades pequeñas
En el dominio suelo dejar los, puertos, dtos, class validators, entidades, y domain service, en la parte de app solo casos de usos y en infra lo divido con primary y secondary. Y utilice los module he inject para facilitar las inyecciones
Tambien se puede hacer como comentas, al final todo es evaluar hasta que punto queremos desacoplarnos del framework y cuanto le queremos dejar entrar, gracias por compartir como lo sueles hacer, seguro que a muchos compañeros les es util 😁
@@AlbertHernandez Gracias por el video. En mi caso también me gusta poner las validaciones en el dominio porque si llamo al caso de uso desde otro lugar que no sea el controlador me aseguro que se valide la entrada.
Muy buen contenido! Desconozco un poco Nestjs. pero si me interesa ver como propones usar un controller para abstraer el decorador de @transaction.. Y GRPC, kafka o Rabbit no estaría mal para darle continuidad a este vídeo, y casi casi, una saga
Gracias! Mas que en el controller lo del transaction igual lo meteria en un middleware, ya sea de http o incluso si estamos en CQRS en uno de buses, ya depende de lo que nos interese Me apunto lo de traer esos videos 😁 Un saludo!
Solo por despejar mi duda, no estaríamos rompiendo algún principio cuando creamos los pagos?, al enviarlo por post y a su vez devolver el resultado de la entidad creada? Cuál sería el principio que rompemos ?
Buenas! No se si te refieres a que si esta mal que un método Post devuelva datos, pero si es eso yo no lo veo mal, es muy habitual que devuelva datos que luego necesite el cliente para saber los resultados de la operación, aqui podriamos incluir cosas como el identificador del recurso, url de donde se puede encontrar y asi luego poder utilizarla o incluso si estamos asumiendo datos por defecto luego podrias devolverlo en la propia respuesta para que el cliente los conozca
Siempre me ha dificultado entender los contextos para cuando trabajo con microservicios. En qué casos existiría más contextos?, en tu ejemplo gestionas todo lo de payments que también lo podríamos entender como un microservicio, pero tiene sentido envolverlo en contextos sabiendo que solo manejaremos payments?
Buenas! Pues depende de como diseñemos esos microservicios, si solamente vamos a tener un contexto por microservicio y repositorio si que podríamos quitar esta carpeta, aquí ya va a depender mucho de lo que tengamos. Lo bueno de tener esto de contextos es que nos va a permitir tener: - Un monolito modular, donde se despliegue todo junto pero teniendo esta separación de responsabilidades en distintas piezas, donde en un futuro si quisiéramos desplegarlas por separado lo tendríamos más sencillo - Podríamos ir con una solución de monorepo, donde cada contexto si que sea un microservicio pero tengamos todo en el mismo repositorio Como te comento, al final esto depende mucho de como queramos estructurar los proyectos, lo mejor es que al final es solo una carpeta donde podemos comenzar sin tenerla si creemos que no la vamos a necesitar y si luego vemos que si, ahí ya crearla en un momento y hacer un pequeño refactor
Hola Albert, queria saber como manejas las relaciones entre modelos dentro de la architectura, por ejemplo, la relacion entre User -> Payment y viceversa.
Pues va a depender mucho del caso pero si uno no puede existir sin el otro, por ejemplo, un pago siempre va asociado a un usuario, puedes guardar el id del usuario en tu modelo de pago
Gracias por responder@@AlbertHernandez, ciertamente todo depende del caso, pero me queda la incertidumbre porque si las entidades estan a lo mas interno de la arquitectura, como se comunican cuando necesitas tener informacion de pago de un usuario tomando en cuenta que los contextos son /users y el otro es /payments
@@AlbertHernandez También tengo dicha duda, estaría bueno un video que explicara como se integran dichos servicios y buenas practicas, ya que considero que el problema de la arquitectura hexagonal es que puede llegar a ser un enredo cuando toca interactuar entre modelos, ejemplo tener que llamar un modelo dentro de otro.
Si, lo entiendo, puede llegar a ser muy confuso sobretodo si es la primera vez que se ve, intentaré traer algun video donde se vea como se puede solucionar todo esto
algo q siempre e leido es q el dominio debe ir desacoplado de cualquier framework libreria etc pero aca veo q estas usando la libreria uuid dentro del dominio para generar los id ?
Si, en este caso uuid es un formato universal independiente del lenguaje y es lo que uso como identificador en mi dominio. Aqui tenemos dos posibles soluciones, implementar nuestro propio creador de ids usando este standard o usar alguna libreria de terceros que nos de esto, en este caso suelo preferir usar la libreria de tercero. Lo ideal es luego centralizar en un unico punto esto y si cambia la libreria que solo cambiemos una cosa de nuestra app
Hola Albert Voy a empezar un proyecto nuevo parecido al de mi comentario anterior y me gustaría utilizar ese template, si pudieras revisarlo y ver el error te agradecería mucho. Estoy teniendo problemas con el template de tu github nestjs-hexagonal-architecture-example Monté el contendor de docker pero en los logs tiene un problema con el logger de pino se que es algo que puedo quitar al ser un logger custom, pero tiene interceptores y todo, me gustaria conservarlo.
Buenas! Dale un vistazo mas que a los example a los que tengo de template, esos están mas pulidos y creo que ya no te encontraras esos problemas De todas maneras le dare un vistazo a ese de example para ver si me pasa lo mismo que comentas
Hola @gabrielluna2474! Estoy revisando y me esta levantando el contenedor de docker bien, no se que te pueda estar pasando. Si ves que te sigue pasando crea mejor una issue en el repositorio y lo manejamos mejor ahí, que al final tenemos mas herramientas para compartir código / imágenes y otros compañeros pueden ayudar a investigar también
No tiene sentido estod videos, hacelo con express pero forzar una arquitectura distinta a la q propone nest es mala idea. Es como ir a jugar al futbol a una cancha de básquet.
No coincido con lo que dices, la arquitectura de una aplicación va en base a las necesidades del proyecto y del equipo que tengamos, lo bueno que tiene NestJS es que es flexible y se puede adaptar a distintas maneras de trabajar, podemos empezar con la propuesta del framework que para muchos casos va bien pero si lo necesitamos podemos ir a una hexagonal o la que sea necesario. Es mas, hasta la propia NestJS en sus cursos oficiales como en el de arquitectura y patrones avanzados (courses.nestjs.com/#architecture), muestra como plantean ellos el uso de Hexagonal o DDD en el propio framework
Os dejo aquî el link al repositorio de Github
- github.com/AlbertHernandez/nestjs-hexagonal-architecture-example
Me viene muy bien este video Albert, muchas gracias.
Un placer! 😜
Excelente, sigue trayendo estos videos, son muy buenos!
Gracias 😁
Hace un par de meses realicé un proyecto donde apliqué la clean y me doy cuenta que estuvo relativamente bien implementada, lo unico que no implementé fueron los dtos tanto de aplication como de infraestructure, en su lugar use meras intefaces lo cual sigue siendo muy parecido, estoy contento con la aplicacion implementada. Gracias por este contenido ❤
Fantástico 👏, la primera vez que se implementa siempre surgen dudas, y sobre todo si es en un framework que cuesta el poder separar las cosas y no acoplarse. Yo, por ejemplo, sí suelo separar los DTOs de aplicación y de infra por dolores que he sufrido al no hacerlo, ya que, por ejemplo, la API que estás exponiendo puede ser en snake_case, y luego tú siempre quieres trabajar con camelCase, que es el estándar de NodeJS. Entonces, sería en ese punto donde podríamos hacer toda esa conversión. También serían esos DTOs donde pondríamos cosas como la documentación de Swagger de la API, y tener eso en la capa de aplicación no me termina
Hola Albert! Un poco tarde pero por aquí siempre, tú sabes jaja. Felicidades, está de lujo el video. Veo que en tu repositorio incluyes ya temas de testing que cubren bastante, crees poder traernos en algún momento testing para este proyecto? Estaría de lujo!
Hey! Gracias por siempre estar apoyando hehe, pues si, tengo pensado traer cosas de testing en futuros videos pero voy poco a poco que no me da para todo haha pero lo traeré 😁
Eres el mejor me quedo super claro esta arquitectura y mas el empleo en nest js
Me alegro de que te quedara todo claro 😁
Felicidades por el video Albert. Hice un proyecto bastante parecido al tuyo incluyendo eventos de dominio, testing, base de datos, value objects, etc. Pronto lo subiré a github y te paso el link de medium por si le quieres echar un vistazo :)
Lo único que me chirría un poco del video es la parte de tener que forzar a tu dominio a crear clases abstractas en lugar de interfaces para evitar el uso del famoso "@Inject('Interfaz')" de inversify en cada constructor. Creo que es algo muy particular del framework nest js y que si mañana cambiáramos de framework quizás no tendría sentido y si utilizar interfaces, no sé, es una reflexión que quería compartir contigo.
Gracias por compartir el contenido
Gracias! Si cuando lo tengas pasa link y le daré un vistazo, gracias por compartirlo también :)
Respecto a lo de la clase abstracta si, coincido, al final es el trade-off que estoy pagando por el hecho de no poner el Inject del framework en el dominio, también al usar clases abstractas puedo usar ciertos helpers de jest para generar mocks automáticamente que me vienen bien así que bueno, es un precio que no me sabe tan mal pagar hehe
Un saludo!
estaria bien un video para dokerizar el proyecto con buenas practicas
Buenas! Pues justo todo el docker que esta en este proyecto si que esta hecho en un video donde explico paso por paso como se crea y se ve en mas detalle hehe, te lo dejo a continuación por si quieres darle un vistazillo, y cualquier feedback o cosa que veas que no queda clara me dices y asi intento hablar de ello en futuros videos :D
th-cam.com/video/J4J2wgZ8yWE/w-d-xo.html
Buen video, pero me hubiese gustado ver la diferencia entre un caso de uso y un servicio de dominio o para que sueles utilizar los servicios de dominio y poder haber visto un ejemplo
Gracias! Me lo apunto para ver si puedo traer un video aparte explicando lo de los servicio de dominio
uff gracias por la explicacion... y gracias a yt por recomendarme el canal jajajajjaajja... hace rato que buscaba algo asi con nestjs(amo el framework ojala perdure y logre afianzarse aun mas) y no encontre casi nada... y con eso me aparecieron muchas dudas... si hacerla de 0 o respetar la que ofrece nest de manera predefinida etc... saludos desde Argentina... vi que tienes varios mas de nestjs voy a ponerme al dia jejejje
Un placer! Qué bueno que youtube comience a recomendar mas el canal 🚀
Dale caña, hay varios videos de NestJS en el canal y luego tambien mas generales de Node, que tambien se pueden aplicar al framework hehe
Lo de respetar la manera de NestJS depende mucho lo que quieras conseguir, puedes desde ir a full con el framework, hasta aislarlo del todo, y luego siempre tienes el punto intermedio que también suele ser muy buena opción hehe
excelente albert gracias saludos!
Gracias 💪😁 Un saludo!
Excelente video. Tal vez se podría complementar en el mismo sentido de la arquitectura pero sobre testing.
Gracias! Pues voy a ver si puedo traer algún video de testing en este tipo de arquitecturas, gracias por la sugerencia :D
Albert, espero estes bien. Regreso de un buen tiempo luego de haber visto y aplicado el video (que por cierto, gracias, está muy valioso como todos) y me surgió una duda cuando mencionaste el tema de crear un decorador Transactional, cómo sería una implementación de transacciones en arquitectura hexagonal? Podrías de pronto hablar de eso en un video? Gracias nuevamente!
Muy buenas Juan!
Pues para implementarlo hay varias opciones, una de ellas es en la capa de infrastructure crearte tu decorador transactional, los tipicos de Typescript y ahi que sea donde creas la transaccion y cuando ha acabado que haga el commit y en caso de que falle el rollback, he encontrado esta libreria que ya da una posible implementacion de este transactional por si le quieres dar un vistazo: www.npmjs.com/package/typeorm-transactional
De todas formas, lo mas probable que en un futuro video hable de todo esto y como lo podemos implementar nosotros mismos si
Un saludo
Excelente video! Bien explicado. He implementado esta manera de hacer de hacer un proyecto, pero simore tengo unas de como hacer los casos de uso cuando se trabaja con relationes; como por ejemplo la relation one to many o many to many. Me gustaria una explicación de eso
Gracias 😁 Me apunto eso de las relaciones para traerlo en un próximo video. Si te sirve para ir avanzando la idea es que todo ese tema de relaciones lo puedes ir consiguiendo añadiendo los ids en las entidades que se relacionan, o en en caso de que siempre siempre vaya junto, directamente puedes poner uno dentro de otro, pero hay que tener cuidado luego con esto ya que la idea principal es tener entidades pequeñas
Buenisimo
Muchas gracias! 💃💃
muy bueno el video, bien explicado. A la espera de mas videos sobre arquitectura de software 🤗consulta: que tema de webstorm usas? saludos
Gracias 😁 Pues uso el tema de Monokai Pro (Filter Machine). Un saludo!
En el dominio suelo dejar los, puertos, dtos, class validators, entidades, y domain service, en la parte de app solo casos de usos y en infra lo divido con primary y secondary. Y utilice los module he inject para facilitar las inyecciones
Tambien se puede hacer como comentas, al final todo es evaluar hasta que punto queremos desacoplarnos del framework y cuanto le queremos dejar entrar, gracias por compartir como lo sueles hacer, seguro que a muchos compañeros les es util 😁
@@AlbertHernandez excelente contenido
@@AlbertHernandez Gracias por el video. En mi caso también me gusta poner las validaciones en el dominio porque si llamo al caso de uso desde otro lugar que no sea el controlador me aseguro que se valide la entrada.
Muy buen contenido! Desconozco un poco Nestjs. pero si me interesa ver como propones usar un controller para abstraer el decorador de @transaction..
Y GRPC, kafka o Rabbit no estaría mal para darle continuidad a este vídeo, y casi casi, una saga
Gracias! Mas que en el controller lo del transaction igual lo meteria en un middleware, ya sea de http o incluso si estamos en CQRS en uno de buses, ya depende de lo que nos interese
Me apunto lo de traer esos videos 😁 Un saludo!
@@AlbertHernandez gracias por la info!
Pondré en práctica el vídeo y estaré pendiente a los vídeos!
Solo por despejar mi duda, no estaríamos rompiendo algún principio cuando creamos los pagos?, al enviarlo por post y a su vez devolver el resultado de la entidad creada? Cuál sería el principio que rompemos ?
Buenas! No se si te refieres a que si esta mal que un método Post devuelva datos, pero si es eso yo no lo veo mal, es muy habitual que devuelva datos que luego necesite el cliente para saber los resultados de la operación, aqui podriamos incluir cosas como el identificador del recurso, url de donde se puede encontrar y asi luego poder utilizarla o incluso si estamos asumiendo datos por defecto luego podrias devolverlo en la propia respuesta para que el cliente los conozca
Siempre me ha dificultado entender los contextos para cuando trabajo con microservicios.
En qué casos existiría más contextos?, en tu ejemplo gestionas todo lo de payments que también lo podríamos entender como un microservicio, pero tiene sentido envolverlo en contextos sabiendo que solo manejaremos payments?
Buenas! Pues depende de como diseñemos esos microservicios, si solamente vamos a tener un contexto por microservicio y repositorio si que podríamos quitar esta carpeta, aquí ya va a depender mucho de lo que tengamos. Lo bueno de tener esto de contextos es que nos va a permitir tener:
- Un monolito modular, donde se despliegue todo junto pero teniendo esta separación de responsabilidades en distintas piezas, donde en un futuro si quisiéramos desplegarlas por separado lo tendríamos más sencillo
- Podríamos ir con una solución de monorepo, donde cada contexto si que sea un microservicio pero tengamos todo en el mismo repositorio
Como te comento, al final esto depende mucho de como queramos estructurar los proyectos, lo mejor es que al final es solo una carpeta donde podemos comenzar sin tenerla si creemos que no la vamos a necesitar y si luego vemos que si, ahí ya crearla en un momento y hacer un pequeño refactor
Hola Albert, queria saber como manejas las relaciones entre modelos dentro de la architectura, por ejemplo, la relacion entre User -> Payment y viceversa.
Pues va a depender mucho del caso pero si uno no puede existir sin el otro, por ejemplo, un pago siempre va asociado a un usuario, puedes guardar el id del usuario en tu modelo de pago
Gracias por responder@@AlbertHernandez, ciertamente todo depende del caso, pero me queda la incertidumbre porque si las entidades estan a lo mas interno de la arquitectura, como se comunican cuando necesitas tener informacion de pago de un usuario tomando en cuenta que los contextos son /users y el otro es /payments
@@AlbertHernandez También tengo dicha duda, estaría bueno un video que explicara como se integran dichos servicios y buenas practicas, ya que considero que el problema de la arquitectura hexagonal es que puede llegar a ser un enredo cuando toca interactuar entre modelos, ejemplo tener que llamar un modelo dentro de otro.
Si, lo entiendo, puede llegar a ser muy confuso sobretodo si es la primera vez que se ve, intentaré traer algun video donde se vea como se puede solucionar todo esto
@@AlbertHernandez Muchísimas gracias!
algo q siempre e leido es q el dominio debe ir desacoplado de cualquier framework libreria etc pero aca veo q estas usando la libreria uuid dentro del dominio para generar los id ?
Si, en este caso uuid es un formato universal independiente del lenguaje y es lo que uso como identificador en mi dominio.
Aqui tenemos dos posibles soluciones, implementar nuestro propio creador de ids usando este standard o usar alguna libreria de terceros que nos de esto, en este caso suelo preferir usar la libreria de tercero. Lo ideal es luego centralizar en un unico punto esto y si cambia la libreria que solo cambiemos una cosa de nuestra app
Hola, que buen video, muchas gracias. Que fuente y tema usas en WebStorm?
Gracias ^^ Pues uso la de Jetbrains Mono y el tema de Monokai Pro (Filter Machine)
excelente video! estas utilizando visual studio code? me parece muy distinto el editor que mostras
es intellij
En realidad es WebStorm hehe se me acabó la licencia de IntelliJ pero me dieron de WS 😁
context se lo pdria llamar? modules
Si, no habría problema, el nombre que mejor te encaje al final es una nomenclatura de equipo
Hola Albert
Voy a empezar un proyecto nuevo parecido al de mi comentario anterior y me gustaría utilizar ese template, si pudieras revisarlo y ver el error te agradecería mucho.
Estoy teniendo problemas con el template de tu github nestjs-hexagonal-architecture-example
Monté el contendor de docker pero en los logs tiene un problema con el logger de pino
se que es algo que puedo quitar al ser un logger custom, pero tiene interceptores y todo, me gustaria conservarlo.
Buenas! Dale un vistazo mas que a los example a los que tengo de template, esos están mas pulidos y creo que ya no te encontraras esos problemas
De todas maneras le dare un vistazo a ese de example para ver si me pasa lo mismo que comentas
Hola @gabrielluna2474! Estoy revisando y me esta levantando el contenedor de docker bien, no se que te pueda estar pasando. Si ves que te sigue pasando crea mejor una issue en el repositorio y lo manejamos mejor ahí, que al final tenemos mas herramientas para compartir código / imágenes y otros compañeros pueden ayudar a investigar también
¿Qué editor de código utilizas?
Buenas! Pues utilizo WebStorm 😁
Nah este video me lo veo porque me lo veo
Haha dale a tope, ya me dices que tal cuando te lo acabes 😁
No tiene sentido estod videos, hacelo con express pero forzar una arquitectura distinta a la q propone nest es mala idea.
Es como ir a jugar al futbol a una cancha de básquet.
No coincido con lo que dices, la arquitectura de una aplicación va en base a las necesidades del proyecto y del equipo que tengamos, lo bueno que tiene NestJS es que es flexible y se puede adaptar a distintas maneras de trabajar, podemos empezar con la propuesta del framework que para muchos casos va bien pero si lo necesitamos podemos ir a una hexagonal o la que sea necesario.
Es mas, hasta la propia NestJS en sus cursos oficiales como en el de arquitectura y patrones avanzados (courses.nestjs.com/#architecture), muestra como plantean ellos el uso de Hexagonal o DDD en el propio framework