Profundizando en Clean Architecture: Consejos para Desarrolladores 

Blog: www.netmentor.es/entrada/clean-architecture twitter: twitter.com/NetMentorTW

Yo me he basado en esa plantilla por años y he visto los vídeos de Jason Taylor (muy buenos) desde las primeras versiones de su propuesta de clean architecture y aquí van varias cosas que quisiera comentar: - Min 7: Es real que hace una dependencia directa a EF Core por que IApplicationDbContext utiliza los DbSets de EF Core, pero la razón de eso (y estoy de acuerdo) es que, en la mayoría de los casos, no necesitarás cambiar de base de datos y si lo llegares a necesitar, EF Core ya es un Repository y UnitOfWork. Él llegó a esa conclusión (y la comparto) por lo que él decidió hacerlo así, al final, sigue siendo una propuesta _opinionated_ que a él le funciona y que cada uno debería de llegar a sus conclusiones. Por lo que, romper esta regla es por decisión y no ignorancia. - Min 11 aprox: También considero que no todos los proyectos requieren de un Clean Architecture, ya que son muuuchas reglas, y más si le metes DDD, pero la plantilla general de Jason Taylor, yo siempre la uso (a excepción si es un POC o cosas desechables) pero para proyectos que serán usados y mantenidos por un equipo, por default me voy con esa plantilla, porque aunque se dice ser "Clean architecture" no es tan estricta, y la plantilla ya tiene todo los cross cutting concerns listos, simplemente crear Features con Queries y Comandos (sin tener que mantener un Repository, y cualquier cosa de Domain Driven Design queda opcional). - El uso de interfaces (contratos), sí o sí, las debes de usar cuando hablas con cosas externas (enviar correos, procesar "algo", facturación, etc etc) y generar bien tus contratos, te ayudará muchísimo, esto me ha ayudado a mejorar el cambio de implementaciones y de proveedores con una facilidad (o sea, ports & adapters). - Y a externo también hablo de librerías (excepto EF Core, jaja 😅😅). Un ejemplo: He tenido que implementar el manejo y generación de documentos de Word partiendo de plantillas y Merge Fields, no todas las librerías tienen ese soporte, por lo que por ahora uso una que considero lenta, pero está todo listo para cambiarla en caso de ser necesario, con un contrato bien definido, las otras "capas" puede que ni se enteren. El almacenamiento es otro ejemplo, tengo el contrato bien definido, una implementación de Azure Blobs y ahora lo cambiamos a Office 365 (sharepoint), para la aplicación, es intercambiable sin problema. - Debes de llegar a tus conclusiones, siempre. Buscar en distintos lugares te ayuda a enriquecer tu criterio, Jimmy Bogard, DevMentors, Steve Ardalis, Mukesh, Jason Taylor y nuestro host, NetMentor, podrían tener opiniones diferentes en cómo organizar un proyecto, pero todas son enriquecedoras y apuntan siempre a los mismos fundamentos. - La propuesta de Jason Taylor se me hace muy bien organizada y no es estricta, pero si quieres hacer las cosas bien, conocer los fundamentos es esencial y no solo hacer las cosas por hacerlas - Yo sigo utilizando esta especie de plantillas, sea en una solución con 4 proyectos o en 1 (csproj), la organización la hago igual, esta es una especie de clean con vertical slice, por lo que organizar por features, para mi es lo esencial. - Conocer patrones como Decorator, Strategy o Factory, son bien necesarios, porque de nada sirve tener esta plantilla "Clean" si hacemos puro spaguetti. - A lo anterior, no siempre empieces con patrones, el mismo código te dirá cuando implementarlos, por lo que, refactorizar es vital, super vital, en el ciclo de vida del desarrollo Si llegaste hasta aquí, saludos 🫡

Hola Ivan! Excelente video, me preguntaba si podrías considerar hacer un video sobre "Multi-Tenancy" y la implementación con Entity Framework Core, muchas gracias!!

Yo empecé a usar clean architecture desde have 7 años pero era a medias, jamas fue bien implementado y apenas hasta mi mas reciente trabajo tuve la libertad y tiempo de yo hacer el template para los proyectos de mi empresa donde tenemos sistemas altamentes complejos y capacite a mis compañeros y la verdad les gusto mucho y fue facil de explicar, yo no le veo lo complejo a clean architecture, no son tantas capas de 4 a 5 y cada una tiene su función asi que la aprendes a modificar con facilidad, para mi con 12 años de experiencia laboral ya no hay vuelta atras, sistema chico o complejo teniendo ya mi propio template no hay forma que no vaya a otro tipo de estructuras que ya me pase por todas prácticamente. Y si alguien quiere aprender clean architecture desde las bases y con un maestro de primera busquen los cursos de Miguel Muñoz Serafín que es un MVP de Microsoft con añales de experiencia.

Clean Architecture en mi opinión y experiencia, podría decir que es la aplicación de principios, patrones y buenas prácticas de desarrollo de software.

Estoy revisitando este video despues de un par de semanas y estoy aun más de acuerdo que en un principio. Estoy trabajando en una app que fue creada con esta idea de "Clean Architecture" en lugar de simplemente agrupar todo por features y es una pesadilla entrar al equipo para ver que la constante es añadir pequeñas features pero para hacerlo deber revisar 20 folders y añadir cositas por aqui y por allá.

Excelente! Comparto básicamente todas las opiniones que dijiste en el vídeo. Muy bueno. Al final, como siempre cada herramienta es para cada problema. There Is no silver bullet!

Gracias saludos de Chile

Gracias ❤

Lo mejor es hacerse una plantilla Multiplatform propia : con identidad externa (openidc) + multitenant ( Claims ) con varios proyectos ( blazor + RCL(Razor Component Library ) + Servicios + RealtimeSignalR + Modelos + Maui(Hybrid) + Api1(Redis) .. Api2.. etc.. ) y utilizar Interfaces dentro del RCL donde están los componentes razor

Excelente, pienso lo mismo 😊

Te felicito por tu canal, te escucho y en unos puntos estoy de acuerdo contigo y en otros no. Mi punto de vista sobre el tema; como desarrollares es no hacer código monolítico, es usar las abstracciones(interfaces) e inyección de dependencias, que el proyecto se despliegue monolíticamente en un server, eso es otra cosa. Pero cuando venga la refactorización sea mas mantenible. Saludos.

Gracias Ivan por lo videos....yo también pensaba que Clean Arch. era la panacea pero veo que quizá es lo que dices de demasiada "burocrácia". Una solución quiza seria lo de vertical slice que entiendo es agrupar todo como en componentes (entiendo) y está todo mas localizado. Espero ese video a ver si me clara algo para un futuro proyecto. A seguir...

Ese tipo de proyecto Clean es para que los arquitectos de software o líder técnico dejen todo el proyecto template listo y configurado para que los desarrolladores solo se concentren en lógica de negocio, ejemplo ellos estarían creando sus validaciones de los request y response, crear su handler de MediaTr(aquí puedes crear tu lógica de negocio) y el líder estaría concentrado en que todos tengan la misma implementación de tus conexiones externas,infraestructuras, conexiones a archivos, implementar los cierres de circuito o resilencia a través de DI sin que los desarrolladores se vean afectado por su lógica de negocio. Cómo explicas en el video, no van a encontrar la arquitectura perfecta que cubra todas las necesidades de un proyecto, pero si pueden adaptarlo a sus requerimientos 😃 y dejan de tener la famosa clase “dios” que tiene cargado varios métodos y su mantenimiento es más difícil con el tiempo.

Hola NetMentor, a mi me gusta realizar clean architecture con mediatr, por la facilidad de implementar transactions, logs, cache con los pipelinesbehaviors aparte que no se requiere estar registrando los servicios, el monton de carpetas tienes razon tampoco me gusta, pregfiero separar por modulos y despues cada modulo tendra su carpeta commands y queries y en cada carpeta las clases que en el nombre este descrito lo que se va a realizar y que su unica responsabilidad sea esa, saludos buena explicacion.

Hola! Excelente video! Me gustaría que analizaras el punto de vista de codelytv sobre este tema, creo que le dan un enfoque diferente a las arquitecturas limpias basadas en dominio DDD

Lo que dices aplica de igual manera a armatostes como CQRS, Arquitectura Hexagonal, etc. Se supone que sirven para poner orden en el caos y muchas veces lo que logran es hacer el código inmantenible. Sobre todo en proyectos donde se combina CQRS con MediatR y Unit-of-Work. Honestamente para que eso se justifique, el proyecto tiene que ser realmente enorme.

Comentas que se debe utilizar clean architecture cuando tienes que validar mucha lógica de negocio, entonces que arquitectura recomiendas utilizar cuando realizas una API CRUD sencilla?

Hola, yo opino igual, no suelo trabajar con Clean Architecture, pero las veces que he trabajado en algún proyecto de FinTech, el desarrollo se realizaba muy lento y pesado.

No encuentro el link al proyecto de GitHub, puedes compartirlo.

Yo estoy contigo. Es más importante cómo se escribe el código que intentar reinventar la rueda para generar mucha más complejidad. Dentro de 10 años nos dirán que Clean Arquitecture es inadecuada y nos venderán otra nueva arquitectura. Tiene que haber un equilibrio para que los proyectos sean mantenibles. La reingeniería no es hacer mejores proyectos. La informática se desarrolló para facilitar la vida del ser humano, no para hacerla más difícil. Por favor, hagamos que la sencillez sea la esencia y objetivo de nuestra profesión.

me encantan tus videos. Quisiera que vieras mi proyecto para darle mejoras utilizo muchas tecnologias clean architecture pero per tiene una peculiaridad que no sabria como explicartelo en un comentario buscando obviamente que me ayudes a mejorarlo ya que tienes mas experiencia. avise y le comparto la repo.

Cómo no amar tener que modificar 8 request handlers para actualizar un bool de true a false desde un endpoint...? 🙂gracias "clean" architecture". Qué haríamos sin ti 🙂

Clean Architecture es un unicornio: no lo he visto en ningún proyecto. Y si los que se supone que deberían ser correctos no lo son, vamos listos xD

Deberías haber mencionado ddd pues sin estos conceptos clean architecture no tiene sentido. El ejemplo del template es demasiado simple, ya que no deja de ser crud y sin lógica de dominio, pero es un template.

El video que esperaba de este canal, lo que no me gusta es que casi todos los ejemplos que veo con .NET de Clean Architecture usan la librería MediatR. Ojalá subas un ejemplo sin MediatR, no me gusta que toda la estructura del proyecto dependa de esta librería.

Me gustaría conocer porque no te gusta el patrón Mediator. Que ventajas y desventajas tiene

Clean Arch? Yo soy más de Italian Pasta Arch.

No comparto tu opinión

1. Me ha faltado que alternativa (rápida) harías con un proyecto cómo el de ejemplo (y algún porqué) 2. Podrías empezar una sección de "analizar proyectos (a nivel de arquitectura)". Cómo el del comentario de @antonio206572 PD: Son críticas constructivas