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.
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
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!
Son muy buenos los videos de arquitectura, me parecen muy importantes para tener una base de como construir correctamente una aplicación.
Gracias, gran valor aportan tus videos!
Me encantan estos vídeos sobre arquitectura
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.
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
que editor o ide es ese?
Jetbrains rider