Implementando Clean Architecture en aplicaciones .NET - Primeros pasos

Primera sesión del entrenamiento Implementando Clean Architecture en aplicaciones .NET - Primeros pasos.
Evento realizado el 21 de febrero de 2022 a través de Microsoft Teams.
Sesiones gratuitas en vivo para la comunidad de desarrolladores .NET.
Estas sesiones están basadas en el entrenamiento Implementando Clean Architecture en aplicaciones .NET - Primeros pasos disponible en ticapacitacion....
Únete al grupo de Facebook y plantea tus preguntas.
/ cleanarchitecture.net

[@coxdeveloperc]

Muy buena explicación, se agradece

[@TomasGarijo]

Llevo muchos años programando, siempre he tratado de mantener código de calidad, mantenible, escalable. Pero es necesario seguir aprendiendo y sobre todo de otros programadores. Gracias por compartir.

[@AutonomusSDK]

Muy interesante la enseñanza, gracias. Consulta, si tengo una app medianamente ERP; para esto puedo aplicar Clean Architecture?. Es decir, debo definir todos los casos de uso para luego crear la maquetación; ya que una ERP engloba muchas app como Logistica, Recursos humanos, Servicios, etc. y cada módulo tiene distintos casos de uso... qué se recomienda para estos casos.

[@guillermocaballeromartel9110]

Buenas tardes, agradecido por los conocimientos compartidos. Lamentablemente el tiempo no me acompaña para estar en los "en vivo". Ya realicé este comentario a través de Facebook. Espero esté planeado subir la grabación del resto de los días. Ojalá puedan confirmar. Saludos cordiales desde Chile.

[@CanalTICapacitacion]

Aquí podrás encontrar los videos del entrenamiento. medium.com/@msmdotnet/introducci%C3%B3n-a-clean-architecture-con-net-parte-1-9db30045f2f2

[@guillermocaballeromartel9110]

@@CanalTICapacitacion se agradece la respuesta y tiempo de dedicación. Saludos cordiales.

[@guillermocaballeromartel9110]

@@CanalTICapacitacion consultas: ¿aún no suben más videos? ¿Sólo está el primero momentáneamente? ¿O estoy buscando mal?. Reitero los agradecimientos.

[@gustavomelendez629]

Pero eso me hace muchisimo ruido, Si el output port es implementado por una capa externa, como podremos testear la capa de business si depende d euna capa externa

[@r.amilcarrivasmarquez2892]

Te estas haciendo la pregunta correcta. Recuerdas cuando usábamos Winamp o Windows media player y le cambiábamos la caratula, había algunas espectaculares y otras muy espartanas, algunas venían con la temática de el juego de moda y otras se parecían al equipo modular de audio que te nías en la sala o el estéreo del carro, imagina que en tu aplicación tienes algo similar pero con el almacen de datos o con la interfas grafica y pudieras cambiarlas como si fueran skin de Windows Media PLayer. Para eso se utiliza un patrón llamado plugin y no es mas que la implementación de SOLID mas específicamente de Open Closed Principle con ayuda de Inversion of Control Principle y también de Single Responsibility Principle y este otro Stable Abstractions Principle que no es SOLID por que trata sobre como se comunican los componentes y también es parte de Clean Architecture, Abstract Factory Pattern y Dependency Injection Pattern. en pocas palabras te estoy diciendo que la interface IoutputPort esta dentro de la capa de Business y la implementación la aras en una clase que estará afuera de esta capa y en otro DLL o incluso puedes implementarla barias veces en DLLs independientes como si fuera un plugin y cuando agás tus pruebas en ves de pasarle la implementación real le pasas una implementación fake o stub que para eso están. Si lo encuentras complicado es por que aquí esta la magia, si llegas a entender esto ya entendiste todo lo que necesitabas. 👍 yo no probaría desde la capa de Business, a mi me gusta mas probar desde los controller y con TDD voy diseñando mi aplicación. las pruebas unitarias las dejo para casos problemáticos. No dudes en exponer tus preguntas y las contesto. Me parece que lo difícil de entender es para que quieres una Clean Architecture, parecería que la meta es implementarla y no es así, la idea de Clean Architecture es que tu aplicación sea de la capa de Casos de Uso a las Entidades, todo lo demás sean plugins, y si tu aplicación tiene 15 anos y desde el principio la implementaste con Clean Architecture, abras ido cambiando los frameWork conforme se han actualizado, abras pasado de dotNet2 a dotNet6, De silverlight a Blazor, de SQL Server a Entity Framework y despues a Entity Framework Core, de WinForm a WPF y despues a WinUI o MAUI. Todos estos cambio harían que tu aplicación no envejeciera y los cambio de frameWork hubieran sido de lo mas fácil ya que los implementaste como pugin. el núcleo de tu aplicación casi no cambiaria en esos 15 anos. por que los caso de uso cambian muy poco. si es un negocio que gestiona el mantenimiento de maquinaria de construcción, 15 anos después tendría los mismo caso de uso que al principio, pero estaría corriendo en android gracias a Xamarin y en uno días o semanas la actualizarías a MAUI sin muchos problemas.

[@patxi4876]

No comparto lo de arquitecto y albañil. ¿Un arquitecto que no pique código habitualmente para qué vale, qué sabe, lo que ha leído por ahí?

[@LadyTrunyx]

Vale para que el cliente este contento y tu puedas cobrar tu sueldo, para eso vale... o piensas que con tu código espaqueti alguien te va pagar algo?. Tirar código cualquiera lo puede hacer con 15 dias de entrenamiento. Acaso piensas que lo que haces es de genio?. Mejor cierra el osico y aprende algo.

[@r.amilcarrivasmarquez2892]

Lo que se quiso exponer es que Hay programadores que no son arquitectos, y por supuesto, hay programadores que son arquitectos. yo soy arquitecto y en cada proyecto me dan un roll diferente. Avece codifico y avece diseño, pero hay compañeros que solo codifican y su meta es ser arquitectos.