Solamente quiero decir que el termino "Vertical Slicing" era algo desconocido para mi hasta este video. Pero después de estar manteniendo durante el ultimo año un proyecto Flutter enorme que está hecho en clean + feature driven development odiaba con el alma que varios metodos de autenticación esten distribuidas directamente en la carpeta /features como carpetas flotando y sin sentido.. y llegue a la misma conclusión que ustedes después de casi 1 año de mucha lectura, consultar codigo abierto y tambien poniendo en practica. Muy importante lo mencionado en el minuto 6:33, creo que es la clave para proyectos mobiles que comparten pantallas con el mismo diseño. Tambien senti ese sentimiento de que el cuerpo me pedia a gritos que meta todos esas carpetas dentro de una mayor jajaja. Genial el video
Que facil y tentador en Flutter hacer todo lo contrario y mezclar todas las capas en un mismo archivo y despues tome semanas intentar saber lo que hicimos o quisimos hacer, jaja
Gran video chicos!! enhorabuena. Corto y al grano. Perfecto. Yo, personalmente, prefiero la segunda forma de vertical slicing ya que: - Si tienes que definir varios dominios seguramente es que no deberian estar en la misma aplicacion (microservicios). - Donde defines aspectos de infraestructura que son cross para toda la aplicación (ejemplos de Java: "MongoTemaplate", "Mensajeria",etc..) - Como seria el manejo de excepciones? Gracias, Un saludo
La arquitectura tanto a nivel de aplicación como de infraestructura emerge según crecen las necesidades del negocio, es decir, emerge con el tiempo. En mis proyectos muchas veces se ha empezado con un prototipo de aplicación MVC ( o cuatro ficheros mal contados PHP ) y en una segunda etapa se evoluciona hacia una arquitectura mas "adecuada" y en una tercera fase, avanzas hacia una arquitectura de microservicios, orientada al dominio etc + con una arquitectura de manejo datos mas compleja.
En este caso separando tanto por carpetas, no podemos usar los access modifiers de java para encapsular los conceptos de la aplicación y por ejemplo no permitir importar un repositorio en una clase de dominio. Ya que practicaménte vamos a tener que hacer todas las clases publicas, ya que si queremos importar un repositorio por decir algo en una clase de una capa de aplicación tendremos este problema, pasa lo mismo y si intentamos aplicar este concepto al desarrollo de librerías, nos obliga a poner publicas algunas clases que no deberían serlo.
Muy bien explicado la arquitectura hexagonal, antes habia leido y trabajado un poco pero no entendía algunas cosas y es verdad que el numero 6 no tiene mucho sentido. SIempre pensé que eran 6 capas pero en la practica me confundía. Aca pude verlo más claro.
Esta presentación en concreto está hecha con Keynote, pero cualquier software de presentaciones moderno como PowerPoint, Google Slides u otros permite hoy en día añadir este tipo de animaciones y slides. Saludos!
¿Cómo harías el seguimiento de esta lógica en una aplicación que haga uso de dos bases de datos, por ejemplo postgres y mongodb? Digo, porque en este caso la capa de infraestructura se vuelve mucho más compleja
Hola! Muy buen contenido, vengo implementando hexagonal en Java y en golang, pero estoy teniendo problemas con Node y nest, podríamos ver un ejemplo práctico con nest? Desde ya muchas gracias
Vengo a ver qué es la arquitectura hexagonal porque tengo una entrevista y no me sonaba mucho y resulta que es la forma con la que llevo trabajando AÑOS 🤣
Hola! muy bien video! ¿cual seria la diferencia entre arquitectura limpia y hexagonal? como seria la estructura de carpetas de una arquitectura limpia en el mismo ejemplo del video?
La forma hexagonal puede ser una referencia a la capacidad de esa figura para llenar un espacio sin dejar huecos entre cada una y lo que ello implica en términos arquitectónicos.
Excelente representación. Para front end me parece genial organizar por features pero para backend (APIs) es mejor mantener los elementos del contexto al mismo nivel, sin boundaries. Es decir, todos los modelos en la carpeta Models, los repositories en la carpeta Repositories, etc. Para aislar, micro-servicios.
Para mi este tema del vertical slicing tiene mucha relación con la delimitación del contexto "Bounded context" ya que si yo quiero crear dicha estructura de carpetas debo definir correctamente las responsabilidades.
Muy interesante, ya conocía "Vertical Slicing" y lo he aplicado a proyectos php nativos sin saber que era "Vertical Slicing" 😅. Quisiera que saber como aplicar estos conceptos con Laravel, ya que provee su propio "orden/estructura".
Muy buena explicación. En temas prácticos, cada uno de esos slicing en una arquitectura de microservicios, no serían bounded context, por lo que deberían ser componentes diferentes, en lugar de estar divididos por carpetas dentro de un mismo componente?
Me encanta el video genial como siempre 😊 Llevo tiempo aplicando Vertical Slicing sin saber que se llamaba así porque mi TOC me obliga a ello 😅. Mi duda es... En el ejemplo que ponéis en caso de ser un microservicio (o microfrontend) ¿No estaríamos incumpliendo el patrón de arquitectura mayor, es decir, separar bien cada microservicio por funcionalidades y contextos? Y por ende tal vez estemos camuflando un mal diseño parcheado con vertical slicing? No se si me explico 😅 Gracias por vuestro contenido, seguid así 🎉🎉
Si trabajamos como recomiendan el vertical slices estamos obligados a crear AllInOne en C# a menos que creemos un proyecto pro cada concepto, yo utilizaria la 2da opción en el minuto 4:13 ya que manejariamos 3 proyectos.
Todo bien, hasta que llega el momento de ver que se hará con las clases adaptadoras, que son usadas indistintamente en varios caso de uso. Imagino que han de utilizar alguna capa de responsabilidad vertical, para que cada slice utilice una unica instancia (SINGLETON) del mismo adaptador.
¿como aplicaríamos entitiy framework en este escenario sin morir en el intento? Por otra parte al aplicar slicing, ¿no rompemos con el patron de arquitectura hexagonal o ddd que indica que domain no tiene que conocer nada excepto a sí mismo? Incluso al relacionar los diferentes proyectos en entidades compartidas, tengo referencias cruzadas, se pierde el control.
Soy muy amante a este tipo de arquitectura y me surge la duda de como se podria hacer la comunicacion "intra-slices" es decir casos donde por ejemplo mis products necesiten algun metodo de application de courses ? como se podria mapear en este caso ?
Super claro en 10 minutos. Tengo una duda, ¿que hay sobre TDD se puede combinar aqui o ya sería otro tipo de arquitectura? No he tenido tiempo de adentrarme a TDD pero tengo entendido que es para las pruebas unitarias. Este video me ha convencido de implementar esta arquitecutra hexagonal. En cuanto a frontend siempre me ha gustado la metodologia de atomic design pero solo hasta los átomos. No se si hablen tambien de cómo implementar sistemas de diseño en la arquitectura hexagonal o esté mas enfocado a funcionalidad. Saludos!
Hola! a mi parece puedes perfectamente combinar TDD con este tipo de arquitectura, ya que realmente TDD no es una arquitectura es una metodologia de desarrollo en donde armas primero tus test y en base a eso vas construyendo código
En el ejemplo que proponen veo que auth utiliza un redis y courses un MySQL, que pasaría si auth también usará un MySQL ? Como se podría compartir esa dependencia, esto es habitual, en una aplicación la mayoría de módulos utilizan un MySQL y solo algunos un redis no todos,
Estimados, tengo una duda. Cuando mencionan "conocer detalles de.." o similares de una capa a otra, a que se refieren exactamente? es decir, por ejemplo, en "Application" no se debe hacer uso de cosas que hay en "Infraestructure" ?
Lo que yo personalmente siento, es que la capa de infraestructure con vertical slicing no me hace mucho sentido. Es una capa donde puntualmente estoy instanciando controladores o haciendo las implementaciones concretas de un repositorio, y todo eso puede vivir en una carpeta por separado de infraestructura. Tener toda las configuraciones de la API de forma cohesionada o agrupada, en lugar de estar dejando cosas dependientes de detalles en cada carpeta infra por modulo. Pensadlo así: De forma abstracta la clean architecture a alto nivel se puede modelar como dos capas: infra y dominio, y luego granularmente nosotros la podemos dividir en 4: Entites, useCases, Adapters , Frameworks & Drivers. El lio es que con el vertical slicing teniendo en cuenta la infra, de una u otra forma por cada slice, estamos dejando detalles de infra , y no sé siente del todo correcto. Un ejemplo concreto es que usualmente en la carpeta shared o apps, tengo otro modulo infra donde temrino importando la infra de cada slice.
ปีที่แล้ว
Esto de toda la vida se ha llamado DDD (Domain Driven Development), y la organizacion de carpetas vale tanto una como la otra... de hecho, yo trabajo en .NET y lo que hago es separar los diferentes dominios en diferentes proyectos... aunque eso depende del lenguaje claro. Si me equivoco y la Arquitectura Hexagonal tiene diferencias con el DDD, me las podríais explicar, por favor?
Yo hay cosas que no termine de entender, que estaría dentro de "Infraestructura" ? No le encuentro sentido mientras Infraestructura no sea la API Le encontraría sentido si fuera API -> Casos de uso -> Dominio. Otra pregunta, cada división del " Vertical Slicing" se puede conocer entre ellas?, por ejemplo, caso de uso de usuario conozca al caso de uso de curso?
Que pasa si tengo una clase que puede ser cross a conceptos. Dónde se posiciona? Es decir, por ej, qué pasa si mis servicios necesitan interactuar con un repositorio el cual no está expuesto. En dónde se debería colocar?
Respecto al screaming architecture ¿si tienes en la carpeta dominio de "courses", me lo invento, 20 value-objects, 10 execepciones, 10 comandos y 20 eventos, ¿recomendáis tener los 60 archivos "tirados" desde la carpeta domain? Yo lo estaba organizando en carpetas, porque después es muy fácil ir a un comando, a una exepción y, sobre todo a un value-object. Si está en la raiz de domain, a pesar de que algunos tienen sufijos (Exception, DomainEvent, Command), los value-objects no lo tienen y cuesta encontrar la entidad o alguna cosa en concreto. Además el ordenado, al ser alfabético, no lo hace por los sufijos (de los que lo tengan), con lo que visualmente tendrás una lista de entidades, value-objects, exepciones y comandos, bastante remezclado. Me gustaría saber vuestra opinión. ¡Muchas gracias!
Efectivamente puedes hacer slicing a medida que tu dominio dentro de tu contexto va creciendo. De repente en el principio no es necesario pero a medida que surja la necesidad hacerlo en función de evitar las abstracciones prematuras. En fin se puede hacer slicing tanto por contexto como dentro del propio contexto.
Creo que hay un error, por la regla de dependencia, infraestructura no deberia importar componentes de dominio, deberia pasar por aplicación y aplicación a dominio, no es que infraestructura puede tener de dependencias componentes de todas las capas inferiores, me parece que no es asi, cada capa debe pasar por la capa previa para llegar a la siguiente, claro, hablando de afuera hacia adentro, ya que dominio no depende de nadie.
De igual manera, dominio que de manera independiente, y en que te parezca que infraestructura no deba conocer las otras capas, pues se puede ver en la misma arquitectura o en tu diagrama de clases y vayas por el mejor camino según tu perspectiva
Pues de poder, puede. La regla de dependencia no lo restringe, de hecho específicamente indica que es asi. Lo que pasa es que lo normal es que infraestructura lo que hace es consumir los casos de uso que se definen en aplicacion porque para eso esta ahi. De hecho en casos muy especificos tu puedes importar una libreria externa en dominio ( ojo que es para casos muy puntuales y que realmente en tu desarrollo debe ser asi) Ahora, como t digo de poder se puede pero para q querria infraestructura comunicarse con dominio? No tiene mucho sentido y a la larga el hacerlo podria llevarte a romper la arquitectura.
Aplicado a SpringSecurity con java. Cuando añades Spring security a tu API con Springboot y autenticas un usuario. ¿Cómo resuelves el siguiente hecho? Que la entity del usuario que debe implementar UserDetails de SpringSecurity; desde la capa de aplication donde tengas el servicio que acceda que deba hacer login y registro , refrescar token, etc.; para que este servicio pueda recuperar esos datos desde el Dominio del usuario con la info de UserDetails, si desde el Dominio no debe acceder a la capa de infra? ¿el objecto usuario de Dominio también deberia implementar userDetails? ¿No debería estar completamente segregado? Como a priori no veo lógico que una clase de Dominio implemente UserDetails; ni tampoco me ha parecido elegante que desde el controlador en la capa de infra se acceda directamente a los repos, lo que hecho es crear un puerto de salida en la capa de aplicación (con su correspondiente repository adapter en la capa de infra) para manejar el la entity del user en lugar de un usuario de Dominio, para que el servicio de uthenticación en la capa de aplicación tenga accesible la entity sin pasar por dominio Gracias de antebrazo
¿Para qué casos en específico es necesario usar esta arquitectura? Porque hasta el momento el patrón MVC te entrega lo mismo que en el video. Código escalable, mantenible, etc.
Estás en la postura de que te convenzan, será difícil. Se usa la arquitectura en capas cuando quieres código más testeable. A diferencia de MVC, las capas se dividen aún más: la base de datos no son solo modelos, surgen los repositorios, los servicios de base de datos, los managers, en infraestructura divides la capa http, socket, tcp, base de datos, etc., Y en la capa de controlador tienes controladores y casos de uso, dónde si cambias la capa de infraestructura no cambia tu caso de uso. No es algo ni tan sencillo ni para todo.
Pero las vertical slices son los dominios mismos, no? que diferencia entre carpeta "courses" que contiene el "course" en el domain? Son los vertical slices los plurales de los domains? Perdonad pero menudo lío :-)
ปีที่แล้ว
No conocía el término arquitectura hexagonal. Cómo se puede escalar una aplicación de Frontend con esa forma de organizar archivos tan compleja? Cómo defines los dominios?. Cómo relacionas los componentes con su URL, Donde agregas los componentes corpatidos? Cómo generas una librería?. Una recomendación que les dejo sobre el video: La arquitectura de un proyecto es diferente a la organización de los archivos en carpetas, y lo que me dio a entender su explicación, es que la arquitectura esta relacionada con la organización del proyecto en diferentes carpetas. Saludos.
Si quieres aprender más, curso de Arquitectura Hexagonal en Frontend: pro.codely.com/library/arquitectura-hexagonal-en-frontend-197663/about/
he aprendido màs en 10 minutos de video en youtube que en una clase de 1h de ingenieria de software en la escuela
Es genial su forma de enseñar!!!!
muy explicativo video, muchas gracias lo entendi a la perfeccion
Arquitectura hexagonal con Typescript y Testing === cursazo
Solamente quiero decir que el termino "Vertical Slicing" era algo desconocido para mi hasta este video. Pero después de estar manteniendo durante el ultimo año un proyecto Flutter enorme que está hecho en clean + feature driven development odiaba con el alma que varios metodos de autenticación esten distribuidas directamente en la carpeta /features como carpetas flotando y sin sentido.. y llegue a la misma conclusión que ustedes después de casi 1 año de mucha lectura, consultar codigo abierto y tambien poniendo en practica. Muy importante lo mencionado en el minuto 6:33, creo que es la clave para proyectos mobiles que comparten pantallas con el mismo diseño.
Tambien senti ese sentimiento de que el cuerpo me pedia a gritos que meta todos esas carpetas dentro de una mayor jajaja. Genial el video
Que facil y tentador en Flutter hacer todo lo contrario y mezclar todas las capas en un mismo archivo y despues tome semanas intentar saber lo que hicimos o quisimos hacer, jaja
Chicos os tengo que aplaudir la magnífica explicación!
Gran video chicos!! enhorabuena. Corto y al grano. Perfecto. Yo, personalmente, prefiero la segunda forma de vertical slicing ya que:
- Si tienes que definir varios dominios seguramente es que no deberian estar en la misma aplicacion (microservicios).
- Donde defines aspectos de infraestructura que son cross para toda la aplicación (ejemplos de Java: "MongoTemaplate", "Mensajeria",etc..)
- Como seria el manejo de excepciones?
Gracias, Un saludo
Me ha encantado este video.
Estas arquitecturas no las conocía...
Muy clara y didáctica la explicacioón y muy bien producido el video. Saludos.
Sois unos cracks chicos, no me puedo creer lo facil que lo habeis explicado. Teneis mi like y mi gratitud eterna. Muchas gracias de verdad :)
Gracias a ti por comentar!
La arquitectura tanto a nivel de aplicación como de infraestructura emerge según crecen las necesidades del negocio, es decir, emerge con el tiempo. En mis proyectos muchas veces se ha empezado con un prototipo de aplicación MVC ( o cuatro ficheros mal contados PHP ) y en una segunda etapa se evoluciona hacia una arquitectura mas "adecuada" y en una tercera fase, avanzas hacia una arquitectura de microservicios, orientada al dominio etc + con una arquitectura de manejo datos mas compleja.
O melhor vídeo de Arquitetura Hexagonal que vi na internet. Só o print da estrutura já explicou tudo 😍
da gusto ver como estos chavales tan jóvenes nos pasan la mano por la cara a algunos programadores viejuners como un servidor
Videazo que se sacaron!
Muy muy bueno el video, la verdad la dieron toda con la explicación, muy clara y concisa. Me suscribo y doy like, muy buen trabajo
En este caso separando tanto por carpetas, no podemos usar los access modifiers de java para encapsular los conceptos de la aplicación y por ejemplo no permitir importar un repositorio en una clase de dominio. Ya que practicaménte vamos a tener que hacer todas las clases publicas, ya que si queremos importar un repositorio por decir algo en una clase de una capa de aplicación tendremos este problema, pasa lo mismo y si intentamos aplicar este concepto al desarrollo de librerías, nos obliga a poner publicas algunas clases que no deberían serlo.
Excelente muy claro fácil de entender
Llevaba aplicando vertical slicing hace ya un buen tiempo sin saberlo 😮
Seria interesante coordinar un contenido para un curso de la documentación usando esta arquitectura
Dejo Like y sub , me parece excelente este contenido y recien veo su plataforma de cursos , este tipo de material es muy bueno
Excelente video quedo clarísimo tema muy interesante y necesario
Muchísimo más claro con el vertical slicing
Muy bien explicado la arquitectura hexagonal, antes habia leido y trabajado un poco pero no entendía algunas cosas y es verdad que el numero 6 no tiene mucho sentido. SIempre pensé que eran 6 capas pero en la practica me confundía. Aca pude verlo más claro.
Excelente resumen y de cómo se hace mal en muchos sitios perdiendo las ventajas que en teoría ofrece
Me encanta la arquitectura hexagonal.
Yo digo que se llame arquitectura pastel de ahora en adelante :p
excelente video, muy bien explicado!
Good! Excelente contenido! 🧞🤯
Que herramienta usan para armar las presentaciones? Les quedan de lujo 👏
está interesante, también quiero saber jaja
Esta presentación en concreto está hecha con Keynote, pero cualquier software de presentaciones moderno como PowerPoint, Google Slides u otros permite hoy en día añadir este tipo de animaciones y slides. Saludos!
Chat GPT 😂
Efectivamente está en concreto está hecha con Keynote, pero a veces también usamos Google Slides, o directamente edición de vídeo en post producción 😊
@@CodelyTV yo lo supe porque en algún momento del vídeo hacen Alt+Tab y se ven las apps abiertas jejeje ojo avizor
¿Cómo harías el seguimiento de esta lógica en una aplicación que haga uso de dos bases de datos, por ejemplo postgres y mongodb? Digo, porque en este caso la capa de infraestructura se vuelve mucho más compleja
Como siempre.... Cracks!
Que chulada de vídeo chichos ❤.
Muchas gracias! Excelente contenido
Hola! Muy buen contenido, vengo implementando hexagonal en Java y en golang, pero estoy teniendo problemas con Node y nest, podríamos ver un ejemplo práctico con nest? Desde ya muchas gracias
Vengo a ver qué es la arquitectura hexagonal porque tengo una entrevista y no me sonaba mucho y resulta que es la forma con la que llevo trabajando AÑOS 🤣
Hola! muy bien video! ¿cual seria la diferencia entre arquitectura limpia y hexagonal? como seria la estructura de carpetas de una arquitectura limpia en el mismo ejemplo del video?
La forma hexagonal puede ser una referencia a la capacidad de esa figura para llenar un espacio sin dejar huecos entre cada una y lo que ello implica en términos arquitectónicos.
Excelente representación.
Para front end me parece genial organizar por features pero para backend (APIs) es mejor mantener los elementos del contexto al mismo nivel, sin boundaries. Es decir, todos los modelos en la carpeta Models, los repositories en la carpeta Repositories, etc.
Para aislar, micro-servicios.
Es tu opinión persona, gracias por compartir
Para mi este tema del vertical slicing tiene mucha relación con la delimitación del contexto "Bounded context" ya que si yo quiero crear dicha estructura de carpetas debo definir correctamente las responsabilidades.
Muy interesante! Gracias!! 😜👌
Tu video aplica la screaming architecture. Todo claro y simple en 9 min.
Excelente resumen.
Muy interesante, ya conocía "Vertical Slicing" y lo he aplicado a proyectos php nativos sin saber que era "Vertical Slicing" 😅. Quisiera que saber como aplicar estos conceptos con Laravel, ya que provee su propio "orden/estructura".
Muy buena explicación. En temas prácticos, cada uno de esos slicing en una arquitectura de microservicios, no serían bounded context, por lo que deberían ser componentes diferentes, en lugar de estar divididos por carpetas dentro de un mismo componente?
Excelente video 🎉
Que buen video!
Me encanta el video genial como siempre 😊
Llevo tiempo aplicando Vertical Slicing sin saber que se llamaba así
porque mi TOC me obliga a ello 😅.
Mi duda es... En el ejemplo que ponéis en caso de ser un microservicio (o microfrontend) ¿No estaríamos incumpliendo el patrón de arquitectura mayor, es decir, separar bien cada microservicio por funcionalidades y contextos? Y por ende tal vez estemos camuflando un mal diseño parcheado con vertical slicing? No se si me explico 😅
Gracias por vuestro contenido, seguid así 🎉🎉
estamos igual XD
GRacias
Si trabajamos como recomiendan el vertical slices estamos obligados a crear AllInOne en C# a menos que creemos un proyecto pro cada concepto, yo utilizaria la 2da opción en el minuto 4:13 ya que manejariamos 3 proyectos.
Sería bueno crear una app con esta arquitectura. De back y front
Todo bien, hasta que llega el momento de ver que se hará con las clases adaptadoras, que son usadas indistintamente en varios caso de uso. Imagino que han de utilizar alguna capa de responsabilidad vertical, para que cada slice utilice una unica instancia (SINGLETON) del mismo adaptador.
¿como aplicaríamos entitiy framework en este escenario sin morir en el intento?
Por otra parte al aplicar slicing, ¿no rompemos con el patron de arquitectura hexagonal o ddd que indica que domain no tiene que conocer nada excepto a sí mismo?
Incluso al relacionar los diferentes proyectos en entidades compartidas, tengo referencias cruzadas, se pierde el control.
Desde el domain de auth, puedes conocer el domain de courses en caso de ser necesario y no romperias las reglas de nada.
Esto se puede aplicar también al backend sin problemas?
Soy muy amante a este tipo de arquitectura y me surge la duda de como se podria hacer la comunicacion "intra-slices" es decir casos donde por ejemplo mis products necesiten algun metodo de application de courses ? como se podria mapear en este caso ?
Super claro en 10 minutos. Tengo una duda, ¿que hay sobre TDD se puede combinar aqui o ya sería otro tipo de arquitectura? No he tenido tiempo de adentrarme a TDD pero tengo entendido que es para las pruebas unitarias. Este video me ha convencido de implementar esta arquitecutra hexagonal. En cuanto a frontend siempre me ha gustado la metodologia de atomic design pero solo hasta los átomos. No se si hablen tambien de cómo implementar sistemas de diseño en la arquitectura hexagonal o esté mas enfocado a funcionalidad. Saludos!
Hola! a mi parece puedes perfectamente combinar TDD con este tipo de arquitectura, ya que realmente TDD no es una arquitectura es una metodologia de desarrollo en donde armas primero tus test y en base a eso vas construyendo código
@@xdneos Muchas gracias !
En el ejemplo que proponen veo que auth utiliza un redis y courses un MySQL, que pasaría si auth también usará un MySQL ? Como se podría compartir esa dependencia, esto es habitual, en una aplicación la mayoría de módulos utilizan un MySQL y solo algunos un redis no todos,
Al hacer el vertical slicing ya no se estaría convirtiendo practicamente en DDD ?
Estimados, tengo una duda. Cuando mencionan "conocer detalles de.." o similares de una capa a otra, a que se refieren exactamente? es decir, por ejemplo, en "Application" no se debe hacer uso de cosas que hay en "Infraestructure" ?
Lo que yo personalmente siento, es que la capa de infraestructure con vertical slicing no me hace mucho sentido. Es una capa donde puntualmente estoy instanciando controladores o haciendo las implementaciones concretas de un repositorio, y todo eso puede vivir en una carpeta por separado de infraestructura. Tener toda las configuraciones de la API de forma cohesionada o agrupada, en lugar de estar dejando cosas dependientes de detalles en cada carpeta infra por modulo. Pensadlo así: De forma abstracta la clean architecture a alto nivel se puede modelar como dos capas: infra y dominio, y luego granularmente nosotros la podemos dividir en 4: Entites, useCases, Adapters , Frameworks & Drivers. El lio es que con el vertical slicing teniendo en cuenta la infra, de una u otra forma por cada slice, estamos dejando detalles de infra , y no sé siente del todo correcto. Un ejemplo concreto es que usualmente en la carpeta shared o apps, tengo otro modulo infra donde temrino importando la infra de cada slice.
Esto de toda la vida se ha llamado DDD (Domain Driven Development), y la organizacion de carpetas vale tanto una como la otra... de hecho, yo trabajo en .NET y lo que hago es separar los diferentes dominios en diferentes proyectos... aunque eso depende del lenguaje claro.
Si me equivoco y la Arquitectura Hexagonal tiene diferencias con el DDD, me las podríais explicar, por favor?
Yo hay cosas que no termine de entender, que estaría dentro de "Infraestructura" ?
No le encuentro sentido mientras Infraestructura no sea la API
Le encontraría sentido si fuera API -> Casos de uso -> Dominio.
Otra pregunta, cada división del " Vertical Slicing" se puede conocer entre ellas?, por ejemplo, caso de uso de usuario conozca al caso de uso de curso?
Ustedes explican muy bien ¿tienen algún curso de Arquitectura Hexagonal en C#?
Por lo que entendí es más o menos parecido a como trabaja su estructura de carpetas NEST js con el trabajo por módulos o me equivoco?
En golang cómo queda mejor aplicado, conjunto por dominio o por layer?
No se puede comprar el curso y ya?
Me encantaría tenerlo!!!! ✨
Las hipotecas a tipo fijo o simple ????
Que sucede cuando tienes clases en comun , como la util formateo de fechas o la seguridad en que parte va ?
hola!! se puede obtener el curso en un único pago ?
Mola. Aunque a veces se os escapa cosas de DDD dentro de esta y hace que sea un poco lioso
Como los aggregates, que tiene su homólogo en ports pero descoloca aquí xD
Tienen algún curso de arquitectura hexagonal el node js
Que pasa si tengo una clase que puede ser cross a conceptos. Dónde se posiciona?
Es decir, por ej, qué pasa si mis servicios necesitan interactuar con un repositorio el cual no está expuesto. En dónde se debería colocar?
Respecto al screaming architecture ¿si tienes en la carpeta dominio de "courses", me lo invento, 20 value-objects, 10 execepciones, 10 comandos y 20 eventos, ¿recomendáis tener los 60 archivos "tirados" desde la carpeta domain? Yo lo estaba organizando en carpetas, porque después es muy fácil ir a un comando, a una exepción y, sobre todo a un value-object. Si está en la raiz de domain, a pesar de que algunos tienen sufijos (Exception, DomainEvent, Command), los value-objects no lo tienen y cuesta encontrar la entidad o alguna cosa en concreto. Además el ordenado, al ser alfabético, no lo hace por los sufijos (de los que lo tengan), con lo que visualmente tendrás una lista de entidades, value-objects, exepciones y comandos, bastante remezclado.
Me gustaría saber vuestra opinión. ¡Muchas gracias!
Efectivamente puedes hacer slicing a medida que tu dominio dentro de tu contexto va creciendo. De repente en el principio no es necesario pero a medida que surja la necesidad hacerlo en función de evitar las abstracciones prematuras. En fin se puede hacer slicing tanto por contexto como dentro del propio contexto.
en qué paquete o carpeta debe ir la clase Constantes?
Creo que hay un error, por la regla de dependencia, infraestructura no deberia importar componentes de dominio, deberia pasar por aplicación y aplicación a dominio, no es que infraestructura puede tener de dependencias componentes de todas las capas inferiores, me parece que no es asi, cada capa debe pasar por la capa previa para llegar a la siguiente, claro, hablando de afuera hacia adentro, ya que dominio no depende de nadie.
De igual manera, dominio que de manera independiente, y en que te parezca que infraestructura no deba conocer las otras capas, pues se puede ver en la misma arquitectura o en tu diagrama de clases y vayas por el mejor camino según tu perspectiva
Pues de poder, puede. La regla de dependencia no lo restringe, de hecho específicamente indica que es asi.
Lo que pasa es que lo normal es que infraestructura lo que hace es consumir los casos de uso que se definen en aplicacion porque para eso esta ahi.
De hecho en casos muy especificos tu puedes importar una libreria externa en dominio ( ojo que es para casos muy puntuales y que realmente en tu desarrollo debe ser asi)
Ahora, como t digo de poder se puede pero para q querria infraestructura comunicarse con dominio? No tiene mucho sentido y a la larga el hacerlo podria llevarte a romper la arquitectura.
Estaria bueno con Angular
👏🏻👏🏻👏🏻👏🏻
Pero la carpeta de Infrastructure se va a repetir mucho innecesariamente, no?
hay algun repositorio que explique usando nestjs
Aplicado a SpringSecurity con java. Cuando añades Spring security a tu API con Springboot y autenticas un usuario. ¿Cómo resuelves el siguiente hecho? Que la entity del usuario que debe implementar UserDetails de SpringSecurity; desde la capa de aplication donde tengas el servicio que acceda que deba hacer login y registro , refrescar token, etc.; para que este servicio pueda recuperar esos datos desde el Dominio del usuario con la info de UserDetails, si desde el Dominio no debe acceder a la capa de infra? ¿el objecto usuario de Dominio también deberia implementar userDetails? ¿No debería estar completamente segregado?
Como a priori no veo lógico que una clase de Dominio implemente UserDetails; ni tampoco me ha parecido elegante que desde el controlador en la capa de infra se acceda directamente a los repos, lo que hecho es crear un puerto de salida en la capa de aplicación (con su correspondiente repository adapter en la capa de infra) para manejar el la entity del user en lugar de un usuario de Dominio, para que el servicio de uthenticación en la capa de aplicación tenga accesible la entity sin pasar por dominio
Gracias de antebrazo
Asi que la arquitectura hexagonal y capas es la misma ?
¿Para qué casos en específico es necesario usar esta arquitectura? Porque hasta el momento el patrón MVC te entrega lo mismo que en el video. Código escalable, mantenible, etc.
Para el caso de vender cursos
Estás en la postura de que te convenzan, será difícil. Se usa la arquitectura en capas cuando quieres código más testeable.
A diferencia de MVC, las capas se dividen aún más: la base de datos no son solo modelos, surgen los repositorios, los servicios de base de datos, los managers, en infraestructura divides la capa http, socket, tcp, base de datos, etc., Y en la capa de controlador tienes controladores y casos de uso, dónde si cambias la capa de infraestructura no cambia tu caso de uso.
No es algo ni tan sencillo ni para todo.
@@ssupercrack Sos un crack
Vertical slicing o Bounded context???
y donde irian los modelos de exceptiones compartidas por la solución?
Y como es que la capa de dominio tiene interfaces repositorio que a fin de cuentas son referencias a implementaciones de la capa framework ?
Suena a componentes sobre componentes
para entender esos temas hay que estudiar los patrones de diseño y que mas, quisiera ser un arquitecto de software
pues solid, libros de arquitectura y ddd
ahora esto quedaria en un monorepo o en varios repos por slicing ?
Nuestra opinión: monorepo 😊
Ese Vertical Slicing no es lo que aplica Django?
Y para backend?
es igual
Pero las vertical slices son los dominios mismos, no? que diferencia entre carpeta "courses" que contiene el "course" en el domain? Son los vertical slices los plurales de los domains? Perdonad pero menudo lío :-)
No conocía el término arquitectura hexagonal. Cómo se puede escalar una aplicación de Frontend con esa forma de organizar archivos tan compleja? Cómo defines los dominios?. Cómo relacionas los componentes con su URL, Donde agregas los componentes corpatidos? Cómo generas una librería?.
Una recomendación que les dejo sobre el video: La arquitectura de un proyecto es diferente a la organización de los archivos en carpetas, y lo que me dio a entender su explicación, es que la arquitectura esta relacionada con la organización del proyecto en diferentes carpetas.
Saludos.
Que pasa si un elemento de vertical slicing comparte un elemento de infrstructura?
misma duda, volver a escribir todo para esa feature no tendría sentido, prefiero tener 3 carpetas para todo el proyecto
Estoy escuchando el vídeo en la calle y se oye bajo el volumen, ojalá pueda mejorar gracias por su trabajo
Y la parte de las inyecciones? como es uu
nunca en mi vida he visto un rpoyecto que lo tengan organizado asi , no se ah
esta es arquitectura para front, que no?
Y donde va mi carpeta Utils? 😂
Al purgatorio 😂
Vertical Slicing = Microservicios? WTF? Nuria ha dicho *stia?!
dijeron que 10 min y el video dura menos de 9, no se si creerles
Y ahora me vendrán todos los boy/girl/fans de codely, pero lo explicado NO es vertical slicing.
Nos encanta seguir aprendiendo. En qué estamos equivocados? Gracias!