👨‍💻 Desarrollando API's con .NET Core y la Arquitectura Hexagonal

En el mundo de desarrollo moderno, las API's son de suma importancia y se encuentran en casi todos los sistemas de la actualidad; ya que estas permiten la interacción y comunicación entre programas sin importar el lenguaje de programación o Framework en el que estas fueron codificados 📲💻. Es por eso que en este vídeo te enseño de forma sencilla como crear API's basadas en el estándar REST, haciendo uso de #NETCore, la plataforma más moderna de #Microsoft de código abierto, multiplataforma y con alto rendimiento 👨‍💻👨‍💻👨‍💻. Además, también conoceras como implementar la Arquitectura Hexagonal, una de las arquitecturas conocidas como Clean Architecture, para que puedas escribir un código mucho más prolijo.
En próximos vídeos veremos más acerca del potencial que nos ofrece esta increíble herramienta.
Podrá encontrar el código de la aplicación, con la implementación de la arquitectura hexagonal en el siguiente enlace: github.com/soy...
Redes:
github.com/soy...
/ soymichelt
Sitio web: soymichel.dev
Publicaciones de JavaScript y Desarrollo en General: / soymichelt

[@andreymolina8516]

Casi se me estalla la cabeza tratando de entender la relación entre entidades y proyectos Jajajaj le echaré varios vistazos hasta entenderlo perfectamente. Gracias por el video!

[@SoymichelDev]

La implementación de la arquitectura hexagonal es un cambio en la forma en la que normalmente desarrollamos. Quizás viendo el código mientras revisas el vídeo puedas comprenderlo un poco mejor, podrás encontrarla acá: github.com/soymichelt/youtube-videos/tree/netcore-with-azure-sql La idea central es obligarnos a aplicar los principios solid y principalmente la inversión de dependencias, prácticando pronto escribirás un mejor código. Saludos

[@gordolibertario8304]

@SoymichelDev Quizás si redujeras un poco la lógica de negocio no seria tan dificil entender las relaciones y el video no duraria tanto.

[@lacuentafeik]

Excelente video!! Tambien te agradezco haber dejado el repositorio en github, lo descargue para ir guiándome con el video porque en VsCode y comparándolo con otro proyecto que no tenia la arquitectura, después de muchas horas por fin lo entendí gracias a ti, en verdad gracias!

[@jorgekretschmayer252]

Excelente video. Ejemplo mínimo indispensable que muestra diferentes conceptos

[@frappo9244]

Buenos videos, estoy aprendiendo arquitectura hexagonal con ellos!

[@DacarSoft]

Excelente video colega, me ha servido bastante, sigue adelante con tu canal.

[@DacarSoft]

15:33, debes hacer una corrección en la nomenclatura, las variables privadas y de solo lectura son las que se escriben con un guión bajo al comienzo, y aca haces lo contrario.

[@eduarsanchez1851]

excelente

[@JGDL315]

Excelente video, me quedo mas claro que con otro videos, una consulta, desde la infraestructura Api, hay forma de hacer una inyección de los servicios en vez de instanciar?

[@SoymichelDev]

Gracias por el comentario 🙏 Definitivamente el principio de inversión de control (IoC) y el principio de inyección de dependencias son unas de las principales técnicas de desarrollo de software, pensando en posibles cambios a futuro. Hacer que nuestro código esté basado en implementaciones en lugar de abstracciones definitivamente no va de la mano con un buen escalamiento. Estás buenas prácticas ya se encuentran soportadas en .NET Core, por lo que no necesitamos en principio herramientas de tercero. Espero poder traer pronto contenido sobre esto. Saludos

[@DacarSoft]

Por que agregas los proyectos como consola en vez de biblioteca de clases?

[@SoymichelDev]

Es un buen punto 🤔, yo suelo usar proyectos de consola para tener una plantilla configurada para ejecutar scripts en las capas en caso de ser necesario. Los ejemplos más comunes es para generar migraciones o disparar eventos para realizar ciertas acciones. Más allá de eso no hay ninguna razón así que perfectamente podrían ser bibliotecas de clases 👌

[@leolasalle]

Excelente video, pero sólo una alcance: las intefaces se implementan, no se heredan.

[@ismaelpolanconunez421]

El video esta muy bueno y todo, pero una observacion y una duda: 1- Algo rapido para personas que no tienen una idea clara. 2- ¿Dónde usas el metodo de la interfaz SaveChanges? Osea, para bases de datos en memoria con solo usar context.Cosas.Add(unaCosa) creo que ya sirve, pero para bases de datos en SQL Server, como aplicas el metodo SaveChanges? En cada metodo del repositorio? Porque si es asi, ya no haría falta una interfaz que implemente dicho metodo.

[@SoymichelDev]

Hola muchas gracias por su comentario estimado 🙏, Respecto a su duda, tiene razón el método SaveChanges dependiendo del tipo de gestor de base de datos y del objetivo podría estar de más. En el caso del ejemplo del vídeo lo que prentendía era mostrar una especie de transacción; o sea, la idea era crear un mecanismo que permita tener algo parecido a commits y rollbacks de una forma sencilla. Entity Framework Core por defecto nos permite gestionar datos de entidades independientes y por conjunto usando transacciones por detrás, entonces si por ejemplo al hacer una venta (que involucra modificar tres entidades: venta, detalle venta y producto) fallaba la modificación de alguna de las entidades me aseguraba de que las otras consultas de modificación a las otras entidades también fallaran. Con esto evitamos que se guarde una venta sin que se descuente la cantidad de los productos que se vendieron y viceversa. En este caso podríamos decir que tu comentario es cierto, en caso de que no sea necesario o no querramos implementar un mecanismo de transacciones que nos asegure la gestión de datos en diferentes entidades simultaneamente. Saludos

[@ismaelpolanconunez421]

@@SoymichelDev Está muy interesante eso que dices. Se nota que eres una persona bien empapada sobre como funcionan los ORMs. En este comentario me acabas de dar otro tutorial jeje. De mi parte tienes un nuevo subscriptor! Muchas gracias por este aporte!

[@franciscopicado2544]

Hola. me ha gustado tu video, buena iniciativa, mas de parte de un Nicaragüense. queria consultarte si es posible el código el proyecto que has explicado, seria un poco mas fácil tener el código para revisar conforme se va viendo el video. Saludes...Suscrito a tu Canal.

[@SoymichelDev]

Hola estimado, muchas gracias, acabo de agregar el enlace del repositorio a la descripción, es el siguiente: github.com/soymichelt/youtube-videos/tree/netcore-with-azure-sql

[@oshoosho4604]

se supone q esto es más fácil de programar, implementar y mantener? tengo mis serías dudas. prefiero la clean arquitectura de spring boot

Buen vídeo, pero estoy viendo un error que hace que se cargue toda la arquitectura... En el minuto 31:10, cuando estás creando el ProductoRepositorio, estás usando AppVenta.Dominio. No se supone que la capa de infraestructura SOLO debería beber de la de aplicación?

[@leolasalle]

Nop. las capas exteriores pueden ver las interiores, pero no al reves. Esa es la restricción.

@@leolasalle Si, totalmente cierto 😄Gracias Leonardo

[@DacarSoft]

Amigo @SoymichelDev, tengo otra inquietud y disculpa, si fueses a implementar Dtos, en que capa lo harias?

[@oshoosho4604]

tengo una pregunta. si alguien preguntara "hay en este ejemplo aplicación de principios solid?", la respuesta sería sí, no? y en caso de ser sí, en q partes? gracias

[@VAF-rq7tg]

Por ejemplo, ha hecho segregación de interfaces (La 'I' de SOLID) cuando implementó las interfaces de repositorio (Agregar, Editar, Listar etc)

[@sandronapan1215]

Hola , como puedo extraer los objetos y crear las entidades, en este ejemnplo creas la base de datos y se crean las tablas, pero como hacer lo contrario crear las entidades desde la base de datos con las tablas, es posible ???

[@leolasalle]

En este ejemplo las entidades de negocio son equivalentes a las del modelo de datos, pero esto no siempre es así. Si tienes la BD antes de la aplicación, deberías aplicar el enfoque DataBase First de EF y generar mappers entre las entidades de BD y las de negocio.

[@AnotherFancyUser]

Buenas!, excelente el video, muy bien detallado. Unas consultas nomás, que no es de la arquitectura per se (o tal vez si). En el metodo donde calculas tax, pones 15, que pasa si en el dia de mañana el impuesto nicaraguense cambia a 20? estarias rompiendo Open Close? Si quisieras sacarlo como harias? un IOptions y ponerlo en el appsettings.json? y si esto fuera una web api lo pones en el contenedor en ConfigureServices? En el contexto veo que pones la connection string, que pasa si mañana cambian la conexion o las credenciales? No te conviene usar el metodo de extension .AddDbContext de EF? Asi lo sacas del "connectionStrings" del appsettings.json, (El problema es que deberias instalar EF en tu capa web api). Otra, vi que en el contexto (y creo que en uno de los servicios) estas haciendo un new de una clase concreta, no te conviene depender de abstracciones? por ej los Configs podrian implementar un IConfig (Si es que ya no existe), y cuando creas un VentaContext por Inyeccion de dependencia, el contenedor ya tenga esos 3 'servicios' ?

[@hernanar3647]

Yo lo haria mediante el IConfiguration (Más sencillo de escalar, y auqe simplemente se puede hacer mediante el AppConfig), pero tendriamos que agregar sanatización del campo

[@SoymichelDev]

Muchas gracias por su comentario 😊 Lo que apuntas son mejoras que debí haber tenido en cuenta en el momento, pero ya que quería hacer una introducción a la arquitectura hexagonal quise enfocarme en los aspectos que consideré más importantes. El TAX definitvamente es una mala práctica, ya que como mencionas eso no escala a futuro. La solución diría que depende del contexto. En caso de que estemos trabajando en un sistema con una única tarifa de impuestos, el uso de variables de entorno o la inyección de un objeto de opciones mediante una abstracción IOptions es una muy buena solución. El problema sería, cuando tratemos de trabajar con múltiples tasas de impuestos (por ejemplo, si nuestro sistema funciona en múltiples países), en donde quizás deberíamos considerar a los impuestos como una entidad de dominio. En el caso de lo que mencionas de la cadena de conexión, yo usaría preferiblemente variables de entorno, porque considero que esto nos facilitaría los deployments y la entrega continua; además, de trabajar en entornos volátiles. Por último, lo de la inyección de dependencias esto definitivamente es una de las mejores prácticas (que incluso podríamos emplear con el principio de inversión de control) y que deberíamos tener en cuenta siempre para mejorar la escalabilidad del software que desarrollamos. Honestamente esto fue algo que consideré, pero a veces suele ser un tema algo complejo cuando se está iniciando. De esto si es algo que pienso traer contenido pronto. Saludos 🙏

[@gordolibertario8304]

Tiene demasiada lógica de negocio este video, se alarga innecesariamente, se viene a explicar como se levanta una API no como se gestiona una venta.

[@SoymichelDev]

@@gordolibertario8304 la idea era hacer una introducción a la arquitectura hexagonal, para ejemplificar el uso de una clean architecure. El detalle está en que eso está muy relacionado con el DDD y no quise deslindarlo de eso. De ahí la necesidad de meter lógica en dominio y casos de uso. De hecho limité bastante eso, al omitir aspectos como value objects, aggregate routes, servicios de dominio, eventos de dominio, etc. Al final trato de hacer una versión minimalista solo utilizando el principio de inversión de dependencias, el principio Open/Close, el patrón repository y mostrando como empujar la lógica hacia las capas más profundas de la arquitectura; es decir, dominio y aplicación. Saludos 🖖

[@gordolibertario8304]

​@@SoymichelDev Claro pero en abierto cerrado usar new está casi prohibido, por eso no noté tu aplicación de solid. Respecto a object values tenias lo necesario para crear al menos uno por entidad, y no representaba una adición importante al codigo que ya habias creado, es decir que te quedaste corto con las explicaciones para la cantidad de codigo que escribiste.