La gran pregunta ¿que es Clean Architecture?
Tras un fantastico curso en TI Capacitación de la mano de Miguel Muñoz Serafin, me he aventurado a crear este blog con la intención de explicar de una forma algo más "común" que es eso de la arquitectura límpia que se esta hablando tanto ahora. Es muy posible que utilice las mismas palabras que este fabuloso profesor, espero que no se moleste.
Respondamos a la prenguna, ¿que es Clean Architecture, o arquitectura limpia? La respuesta más simple sería que es programar utilizando un conjunto de buenas prácticas y patrones para hacer que nuestro código sea más fácil de mantener y escalable. Pero creo que esta respouesta sigue generando muchas dudas, ya que por un lado se me ocurre, ¿y que son las buenas prácticas?, ¿que son "patrones"?.
Buenas prácticas
Buenas prácticas para programar, dentro de un contexto de programación orientada a objetos, usando por ejemplo c#, es hacer un buen uso de los conceptos SOLID. Y de nuevo nos podemos preguntar, ¿que es eso del SOLID? SOLID son unos consejos a seguir cuando se está programando las clases para que tu código sea más "limpio". Para más información pueden consultar los enlaces adjuntos.
Patrones
Los patrones son como "plantillas" con soluiciones a problemas concretos. Hay muchos patrones de programación para solucionar un sin fin de problemas. Algunos de los más utiilzados en arquitecturas limpias pueden ser: Mediator, CQRS, Repository, entre otros.
Muchos nombres, un mismo objetivo
Se puede encontrar muchos tipos de arquitecturas limpias por internet, puedes encontrar la arquitecutera hexagonal, cebolla, de puertos... pero todas buscan lo mismo. Separación de responsabilidades y facilidad para hacer cambios o mantenimiento del software.
Como se puede observar en esta representación se pueden diferenciar cuatro responsabidades. Pero no quiere decir que esta sea la única o la mejor forma de hacerlo, sólo es una representación. Para leer el gráfico hay que hacerlo desde el circulo central hacia arriba.
En amarillo: En este área pondremos todo el código que se pueda compartir entre diferentes áreas o capas del software. Reglas de negocio, entidades POCO, interfaces...
En marrón: Éste es el área donde ubicaremos los casos de uso, o lo que es lo mismo, las clases que van a dar solución a problemas concretos.
En verde: Área destinada para la transformación de los datos desde los casos de uso a la intefaz de usuario, o para comunicarse con el exterior a bases de datos u otros servicios. Aqui colocaremos controlladores, vistas, vistas modelos, presentadores...
En azul: Finalmente el área donde se ubicarán las interfaces de usuario, páginas webs, bases de datos u otros servicios externos.
Inversión de dependencias, la clave de todo
Uno de los principales principios que se sigue en una arquitectura limpia es la invesión de dependencias. En una aplicación tradicional por capas haces referencia directa a la base de datos, y eso hace que tengas una dependencia directa sobre el tipo de base de datos a utilizar, o sobre el tipo de framwork o driver utilizado para el acceso a datos, como peude ser ADO, EntitiFramework, Dapper. Y como no. La forma de codificar dependerá directamente de la procedemcia de los datos, base de datos (MS-SQL, MySQL, ORACLE), desde archivos, de una API. o cualquier otro. Por lo que en una aplicación por capas tradicional tu área marrón dende de tu área verde, y es aquí donde invertimos esa dependencia con abstracciones.
De igualmanera, cada una de las áreas de colores dependen de una abstracción para comunicarse con su capa externa. Las implementaciones se realizarán en el área siguiente. Por ejemplo, para que desde la capa amarilla, donde se encuentran nuestras entidades, se pudiera acceder a algún código de la capa siguiente, en ese caso la marrón, utiliaremos una interfaz, y la implementación residirá en la capa marrón.
Esto genera que podamos sustituir en cualquier momento la capa marrón por otro código, sin que ello afecte a la capa amarilla. De igual manera haremos con todas las demás capas. Y para cruzar los bordes utilizamos clases simples de datos, lo que normalmente se conoce como DTO.
En éste otro gráfico se representa el órden de dependencias, que siempre es hacia abajo, desde la capa más externa a la capa más interna.
Aclarar que esto es sólo una representación, no necesariamente hay que seguir este órden, o definir este tipo de áreas.
Lo más importante es tener claro que las capas deben de comnicarse con abstracciones y utilizar las implementaciones de las capas superiores, para así independizar cada capa de la otra y que pueda ser sustituida fácilmente, mientras se mantenga las reglas definidas en la abstracción.
Conclusiones
En una arquitectura limpia se escribe mucho más código que con la tradicional programación en capas. Ya que si pretendemos seguir excrupulosa y extrictamente todos sus conceptos, nos lleva tener que crear abstracciones e implementaciones para prácticamente todo. Esto es algo que a muchos programadores no les gusta, Como ellos dicen, ¿para qué dividir mi clase en varias mas una abstracción si lo puedo hacre todo en una sola?
En esencia son más los beneficios que se obtienen que el tiempo que se invierte, pero bueno, como resumen clean architecture no es para vagos.
Por otro lado, yo apenas empiezo a introducirme en el mundo de la arquitectura limpia, por eso el título de este blog. Yo soy el primer torpe en esto. Conforme aprenda más y domine altunos temas es posible que que escriba otros blogs.
Por último me gustaría agradecer al Sr. Muñoz sus entrenamientos, que poco a poco me ha hecho crecer bastante, aun tengo mucho que mejorar y cambiar de hábitos, pero algún día lo lograré.