Arquitectura limpia en ASP.NET: cómo diseñarla | DotNet 2021

“Clean Architecture” es un término acuñado por el archiconocido Rober C. Martin (Uncle Bob) con el objetivo en mente de crear una arquitectura donde la separación de responsabilidades mediante el uso de capas sea el pilar principal. En esta sesión veremos como diseñar una arquitectura limpia en una aplicación ASP.NET y aprovecharnos de las ventajas que nos ofrece como evolución más rápida de nuestros productos poniendo especial foco en nuestro negocio (Casos de uso), facilidad en el testing, corrección de errores más rápido, etc. Y por lo tanto conseguir un código más mantenible y flexible a largo plazo. Si te pica la curiosidad y quieres ver como podemos implementar y adoptar este tipo de arquitecturas en nuestros desarrollos no te puedes perder esta sesión.
Speaker:
Luis Ruiz Pavón - Development Lead at Plain Concepts
dotnet2021.com/
[e-mail]

[@eduarsanchez1851]

Excelente contenido

[@andresbeltran5779]

Muy interesante, hay mucho curso de arquitectura limpia, pero realmente no cumplen todos los principios, acá he aprendido un poco más, muy agradecido

[@carlosmorenovelasquez5042]

Gracias por el contenido, de verdad necesito un curso donde pueda aprender a como aplicar las arquitectura limpia en mis pryectos de manera practica

[@mauricio9783]

Muy buen video. Me encantaria poder ver mas en detalle la parte de behaviour unit of work etc. Tienes el codigo subido a git o algun sitio donde pueda encontrarlo?

[@pablomaidana7420]

Que patrones de diseño se utiliza en esta arquitectura?

[@pisxa24]

Buenas!! vais a subir las de DotNET 2022? estuve en Madrid en la conferencia, me pareció muy interesante, y me gustaría volver a verla. Gran trabajo!! Gracias!!

[@PlainTV]

Hola Alex, Muy pronto os mandaremos las charlas a los que asististeis al evento. ¡Nos alegramos de que te resultara interesante! Gracias por tus palabras!

[@pisxa24]

@@PlainTV gracias! tenéis una fecha para ello?

[@diegosasw]

Me ha gustado mucho la explicación teórica. Sin embargo, y si se me permite la observación, ese código no utiliza Clean Architecture, así que ahí va una crítica un poco larga ;-) La capa de Application tiene dependencias a implementaciones concretas. Microsoft.EntityFramework es una implementación concreta. Da igual que sea de Microsoft o que se considere DbContext o DbSet como una abstracción, no lo es. En el caso de Clean Architecture, el ser o no abstracción no solo depende de si es una interfaz o una case abstracta, sino también de si es algo que representa un comportamiento abstracto, desde el punto de vista de nuestra lógica de orquestación de casos de uso (i.e: Application) y de negocio (i.e: Domain). DbContext y DbSet son implementaciones concretas de los conceptos de database relacional y de tabla normalizada. Si en un futuro se desea dejar de depender de Entity Framework y cambiar a otro ORM o incluso eliminar el ORM y pasar a una persistencia no relacional (¿por qué no?), los tests unitarios de la capa de Application se romperán. En otras palabras, el ORM, MediatR o cualquier librería o framework fuera de nuestro control, son parte de la capa de infraestructura, y habría que crear adaptadores e inversión de dependencia para no depender de ello desde Application o Domain. Esa es la verdadera prueba de fuego. Con Clean Architecture se debería poder cambiar un ORM, o in-proc bus, o message bus, o, incluso, paradigma de persistencia por otro sin romper ni un solo test unitario de Application o Domain. Si no se puede, es que tu lógica de orquestación de casos de uso o tu lógica de dominio estarán ligados a herramientas concretas, no es una arquitectura limpia. Por otro lado, se ve algún patrón táctico de DDD como agregados, value objetcts, etc. Pero las abstracciones en Application exponen comportamiento con DbSets y "mentalidad" relacional. No se está abstrayendo ni de la tecnología de persistencia concreta, porque hay dependencia con Entity Framework, ni de la forma en la que se persisten los datos, porque las abstracciones están enfocadas a tablas en un modelo relacional, no a comportamiento y casos de uso. Aunque ese diseño CRUD no tiene nada de malo, no es un diseño dirigido a dominio, sino a persistencia. Con MediatR (que se menciona por ahí) no es posible ser purista en Clean Architecture, ya que MediatR (hasta donde recuerdo) te obliga a que los mensajes (i.e: comandos, eventos, queries) implementen una interfaz de esa librería. Es una herramienta intrusiva en ese sentido. Por supuesto que, siendo pragmáticos, no es grave tener esa dependencia. A mi personalmente no me gusta, y por eso suelo utilizar librerías como Enexure.Microbus que permiten utilizar cualquier objeto como mensaje sin necesidad de marker interfaces.

[@luisruizpavon]

Muchas gracias Diego por la crítica, muy bien explicados todos los puntos, y te lo agradezco de veras un montón el tiempo dedicado. Por supuesto que tienes razón en las cosas que expones sobre que no es la arquitectura limpia tal cual la describe Rober C Martin, pero como bien digo en el vídeo es mi concepto de Clean Architecture (My Clean Architecture quizás no sea correcto decirlo) y estaba seguro que habría gente que no estaría de acuerdo conmigo y lo entiendo perfectamente, pero como siempre digo, me gusta ser pragmático y adoptar aquello que me ayuda pero también trato de adaptarlo a mis necesidades. Esto daría para unas cuantas cañas, pero te voy a comentar sobre algunos puntos y no es por excusarme ni nada :) En referencia a el uso de EntityFramework en la capa de Aplicación, lo he venido usando porque para mi es una abstracción sobre el proveedor subyacente que soporte y si tengo que que ser usar EF y darle concesiones a mi arquitectura y modelos, pues adelante, hasta ahora en todas las aplicaciones que he desarrollado de línea de negocio durante 20 años nunca me he visto en la tesitura de cambiar ni tan siquiera un tipo de base de datos SQL Server por un Postsgres o similares (Eso con EF lo tendría ya cubierto) por eso a día de hoy lo sigo usando y cada vez es menos intrusivo y permite modelar mejor nuestras entidades. Sobre MediatR, pues más de lo mismo, para mi es un win, me ha ayudado a definir una manera de comunicarme con la capa de aplicación y de poder usar behaviors como la parte cross-cutting de dicha capa. No conocía Enexure.Microbus y la voy a echar un vistazo ;) La parte de DDD no es purista, como bien dices tiene concesiones a un sistema relacional, pero aunque no sea purista también me ha funcionado y por eso sigo con esta aproximación. Sobre la parte de test unitarios, solo los hago sobre mi capa de mi dominio o entidades que es donde reside toda esa logica que no depende de nada, para aplicación siempre he usado la aproximación de integración y me ha ido bien hasta ahora. La verdad es que me queda mucho por aprender y mejorar. Ahora estoy leyendo este libro que me ha parecido interesante y toca temas que todavía no he implementado y que me gustaría poder hacerlo en un futuo: www.packtpub.com/product/hands-on-domain-driven-design-with-net-core/9781788834094 Lo dicho Digo, muchas gracias por el comentario! Un saludo.

[@diegosasw]

@@luisruizpavon Gracias a ti por tu respuesta. Es cierto que al final hay que saber cuando dejar lo purista a un lado y ser pragmático, sobre todo alrededor de productos y paradigmas tan estandarizados como EF y bases de datos relacionales, de las cuales EF ya te abstrae. Y cambiar de una persistencia relacional a una no relacional es muy poco habitual. El libro de Alexey Zimarev que mencionas es fantástico. Pero como se ve en la evolución que va haciendo en sus ejemplos, al final uno se acaba preguntando si es realmente "posible" orientarse a DDD utilizando bases de datos relacionales sin caer en demasiada complejidad accidental, sobre todo cuando se usan ORM que te dirigen tantísimo a diseño CRUD. Y se ve por qué Event Sourcing encaja tan perfectamente con DDD. Un saludo.

[@diegosasw]

Un poco off-topic Para un ejemplo de Clean Architecture hice un ejercicio para mis estudiantes. Había que comenzar un proyecto por el dominio, lógica de negocio, OOP a tope, encapsulación, etc. La persistencia se abstraería con patrón repositorio y habría una primera implementación del repositorio en memoria. Ese ejercicio era sencillísimo. Después les propuse un ejercicio "trampa" en el que debían cambiar la implementación del repositorio para usar una base de datos relacional con SQL Server y Entity Framework. Ahí se empezaron a ver muchas cosas y es donde la impedancia objeto-relacional realmente mostró su cara. Se veia que: 1. Persistir era engorroso, por el tema de normalizar un objeto de dominio "complejo" (con estado + comportamiento), pero relativamente sencillo. 2. Recuperar el objeto de dominio, a partir de sus datos normalizados, para hidratarlo/instanciarlo era mucho más engorroso porque, gracias a la encapsulación, no se exponían setters públicos (como bien indicas en tu charla, todo interno en la medida de lo posible). 3. Los ORM incitan a utilizar modelos anémicos. Algunos estudiantes violaron la encapsulación para hacer públicas ciertas propiedades. Otros modificaron el dominio para acomodarlo al modelo relacional. La moraleja era que en muchos proyectos, la persistencia relacional y los ORM no son demasiado compatibles con DDD ni OOP, y que la impedancia objeto-relacional tiene un gran coste en cuanto a complejidad accidental y problemas para implementar Clean Architecture. Aquí dejo el ejercicio por si alguien encuentra un argumento que me haga replantearme mi afirmación rotunda de que los ORM y las bases de datos relacionales son enemigos de DDD. :-) gitlab.com/cenec-20-21/dotnet-repositorio-futbol-efcore

[@luisruizpavon]

@@diegosasw Totalmente de acuerdo contigo, además me parece un ejercicio excelente! La verdad es que este tipo de debates son super enriquecedores y se aprende un montón compartiendo otros puntos de vista. Me apunto el repo en favoritos para ojearlo :) Un saludo.

[@giangomezgc]

Tendras algun demo ejemplo sobre lo que expones. Saludos.

[@MauroBernal]

Cuál es el nombre de la herramienta con la que realiza el análisis?

[@MauroBernal]

Sera ndepend?

[@luisruizpavon]

@@MauroBernal Efectivamente NDepend www.ndepend.com/

[@gerarduab9960]

Sería posible tener el código que analizas en git?

[@luisruizpavon]

Hola Gerard! El código pertenece a una template que hemos desarrollado en Plain Concepts y no me es posible publicar el código. Te voy a pasar una serie de enlaces y videos donde puedes aprender todos los conceptos en los que me he basado para crear la plantilla: Sobre la API Rest tienes estos repositorios que hablamos en otras ediciones: - kzbin.info/www/bejne/j36te5tpqLOoadE - github.com/CarlosLanderas/dotnet2018-aspnet-core-best-practices - kzbin.info/www/bejne/ooSsgXd6rcudq9k - github.com/CarlosLanderas/dotnet2019-aspnet-core-best-practices Sobre test funcionales en ASP.NET Core: - github.com/Xabaril/ManualEffectiveTestingHttpAPI Sobre como diseñar bien objetos: - kzbin.info/www/bejne/sJnUlHiBqbRlkJo - github.com/lurumad/object-design Sobre conceptos cross-cutting con MediatR: - lurumad.github.io/cross-cutting-concerns-in-asp-net-core-with-meaditr Un saludo.

[@gerarduab9960]

@@luisruizpavon Vale Luis, sin problema totalmente entendible. Gracias por la aportación.

[@jonathancondoriquispe9399]

@@luisruizpavon te agradecería mucho si también me pudieras proporcionar tu material de apoyo para poder aprender los conceptos en los que te has basado para crear la plantilla

[@gerardogonzalez2910]

@@luisruizpavon Hola Luis, sería posible pasar algún tipo de scaffold del código con el tema de DomainEvents etc... sin el template? Muchas gracias!