Dios, como no conocía tu canal antes, el único canal con contenido avanzado era de Codely pero no se metían a explicarlo tan a detalle como lo haces tú, muy útil
😲Aunque estoy un poco oxidado en .Net, pude entender lo que es tu arquitectura. Que en sí, cuenta más con lo que uno se sienta cómodo en trabajar. Se nota que tienes gran dominio tanto de .Net como de las arquitecturas subyacentes. Excelente presentación de este tema tan importante. Éxitos en todo. 😎
Mas clara que el agua la explicación, no tengo nada para agregar, solo gracias por compartirla. Suma mucho para personas que no conocen/estan arrancando con arquitecturas
Excelente video. Más allá de la implementación específica presentada (que considero muy acertada, sobre todo porque estoy en contra de crear interfaces para un casos de uso que representan el negocio), lo más valioso es el enfoque pragmático al diseñar arquitecturas de software. Con experiencia suficiente, podemos tomar inspiración de diversas arquitecturas y crear soluciones adaptadas a nuestras necesidades particulares. Es crucial recordar que no existe una arquitectura perfecta universal. Cada proyecto tiene sus propios requerimientos y contextos. Además, aunque no se mencione explícitamente por no considerarse muy 'técnico', el estilo personal y las preferencias del programador también juegan un papel en el diseño arquitectónico.
Estoy ingresando al tema de arquitecturas de software me parece excelente, en mi caso mi empresa debido a que su rubro no es programación estamos estancados pero está pasando no utilizar alguna arquitectura más eficiente
No me parece muy Hexagonal, porque como tal no llamas a un puerto o un adaptador. Pero estoy de acuerdo que simplificar este flujo (Me paso personalmente de simplificar Mediator) quitas una dependencia que en el futuro podría cambiar su configuración. Entiendo que tu capa de casos de uso es un símil a la capa de dominio, y en mi caso me gusta segregarla aún más con servicios, handlers y excepciones propias del negocio. PD: Buen tip del nombrado y manejo de los Unit test. Lo aplicaré en el futuro. Gracias!
Muy buena explicacion, sabes que en mi empresa vamos a dejar de usar excepciones porque nos han generado bastantes problemas y pasaremos a usar ErrorOr, una libreria que esta muy buena para el patron Result y Railway . Tambien nos esta pasando exactamente lo que decias de los handlers que llaman a otros handlers, asi que la idea es encapsular en servicios aquellos comportamientos que debamos reutilizar entre handler y listo, es mucho mas limpio y facil de seguir. Por otro lado tambien venia pensando que usar Controllers en vez de minimal APIs me parece mucho mas prolijo por el tema del versionado de endpoints, documentacion con OpenApi, etc. Saludos genio.
Si buscáis solo un tipo que haga de wrapper errorOr no está mal, pero si buscáis algo mas potente la mía es mejor 👀 Dicho esto, hay proposals para incluir una librería así en las siguientes versiones de .net de forma nativa, aún no hay nada claro pero para que lo tengáis en cuenta. Un saludo
Qué opinas de la arquitectura de monolito modular?, es una arquitectura similar, pero en lugar de tener un Data y un Apis para todo, todo eso se agrupa por módulos, por ejemplo, Auth, Auth tendrá sus propios DTOS, Use cases, unit tests, repository, y demás, siento que sería como que más reutilizable no crees?, me gustaría tu opinión. Ya que por ejemplo, en Angular suelo trabajar de esa forma, y cuando inicio un nuevo proyecto, hay ciertos módulos que suelo reuitlizar, y lo hago simplemente copiando la carpeta relacionada y algunas dependencias.
Por norma general, me parece una buena idea empezar un proyecto con un monolito modular, ya que suele contar con ciertas directrices para dividir el código, lo que lo hace más o menos limpio. El problema surge cuando alguien nuevo llega, empieza a trastear por todas partes y termina mezclando las cosas. Sin embargo, como concepto, si se sabe mantener limpio, es la opción ideal para comenzar.
Yo meto la lógica en el controlador, llamando al context de EF en el mismo controlador y devuelvo objetos dinámicos en el Result ... Y tan feliz oiga!😅
Twitter: x.com/NetMentorTW
Blog: www.netmentor.es/entrada/core-driven-architecture
Hola, Como estas. Haces consultoría online personalizada?
hola buenas si, tanto para empresas como particulares, puedes encontrar más información aquí: www.netmentor.es/ivan-abad
un saludo!
Dios, como no conocía tu canal antes, el único canal con contenido avanzado era de Codely pero no se metían a explicarlo tan a detalle como lo haces tú, muy útil
😲Aunque estoy un poco oxidado en .Net, pude entender lo que es tu arquitectura. Que en sí, cuenta más con lo que uno se sienta cómodo en trabajar. Se nota que tienes gran dominio tanto de .Net como de las arquitecturas subyacentes. Excelente presentación de este tema tan importante. Éxitos en todo. 😎
Son muy buenos los videos de arquitectura, me parecen muy importantes para tener una base de como construir correctamente una aplicación.
Mas clara que el agua la explicación, no tengo nada para agregar, solo gracias por compartirla. Suma mucho para personas que no conocen/estan arrancando con arquitecturas
Gracias, gran valor aportan tus videos!
Me encantan estos vídeos sobre arquitectura
Excelente video. Más allá de la implementación específica presentada (que considero muy acertada, sobre todo porque estoy en contra de crear interfaces para un casos de uso que representan el negocio), lo más valioso es el enfoque pragmático al diseñar arquitecturas de software. Con experiencia suficiente, podemos tomar inspiración de diversas arquitecturas y crear soluciones adaptadas a nuestras necesidades particulares.
Es crucial recordar que no existe una arquitectura perfecta universal. Cada proyecto tiene sus propios requerimientos y contextos. Además, aunque no se mencione explícitamente por no considerarse muy 'técnico', el estilo personal y las preferencias del programador también juegan un papel en el diseño arquitectónico.
Estoy ingresando al tema de arquitecturas de software me parece excelente, en mi caso mi empresa debido a que su rubro no es programación estamos estancados pero está pasando no utilizar alguna arquitectura más eficiente
la gran mayoría de empresas no son de software, eso no debería ser una excusa para no hacer las cosas bien.
No me parece muy Hexagonal, porque como tal no llamas a un puerto o un adaptador.
Pero estoy de acuerdo que simplificar este flujo (Me paso personalmente de simplificar Mediator) quitas una dependencia que en el futuro podría cambiar su configuración.
Entiendo que tu capa de casos de uso es un símil a la capa de dominio, y en mi caso me gusta segregarla aún más con servicios, handlers y excepciones propias del negocio.
PD: Buen tip del nombrado y manejo de los Unit test. Lo aplicaré en el futuro. Gracias!
Muy buena explicacion, sabes que en mi empresa vamos a dejar de usar excepciones porque nos han generado bastantes problemas y pasaremos a usar ErrorOr, una libreria que esta muy buena para el patron Result y Railway . Tambien nos esta pasando exactamente lo que decias de los handlers que llaman a otros handlers, asi que la idea es encapsular en servicios aquellos comportamientos que debamos reutilizar entre handler y listo, es mucho mas limpio y facil de seguir. Por otro lado tambien venia pensando que usar Controllers en vez de minimal APIs me parece mucho mas prolijo por el tema del versionado de endpoints, documentacion con OpenApi, etc.
Saludos genio.
Si buscáis solo un tipo que haga de wrapper errorOr no está mal, pero si buscáis algo mas potente la mía es mejor 👀
Dicho esto, hay proposals para incluir una librería así en las siguientes versiones de .net de forma nativa, aún no hay nada claro pero para que lo tengáis en cuenta. Un saludo
Hola Hola!!... Podrías volver a compartir el GitHub?
Qué opinas de la arquitectura de monolito modular?, es una arquitectura similar, pero en lugar de tener un Data y un Apis para todo, todo eso se agrupa por módulos, por ejemplo, Auth, Auth tendrá sus propios DTOS, Use cases, unit tests, repository, y demás, siento que sería como que más reutilizable no crees?, me gustaría tu opinión.
Ya que por ejemplo, en Angular suelo trabajar de esa forma, y cuando inicio un nuevo proyecto, hay ciertos módulos que suelo reuitlizar, y lo hago simplemente copiando la carpeta relacionada y algunas dependencias.
Por norma general, me parece una buena idea empezar un proyecto con un monolito modular, ya que suele contar con ciertas directrices para dividir el código, lo que lo hace más o menos limpio. El problema surge cuando alguien nuevo llega, empieza a trastear por todas partes y termina mezclando las cosas. Sin embargo, como concepto, si se sabe mantener limpio, es la opción ideal para comenzar.
Yo meto la lógica en el controlador, llamando al context de EF en el mismo controlador y devuelvo objetos dinámicos en el Result ... Y tan feliz oiga!😅
si a ti te va bien, pues bien, pero no hagas eso en entrevistas porque no te cogerán.
@@NetMentor llevo programando .Net desde su inicio ... Tengo más años que Matusalén 😂
Pero hay patrones por todas partes
que editor o ide es ese?
Jetbrains rider