¿Por qué utilizo Clean Architecture?

En este artículo me gustaría explicar los motivos que me llevaron proponer Clean Architecture como arquitectura para desarrollar proyectos en mi empresa. Ahora en mi empresa se desarrollan los proyectos siguiendo esta arquitectura y yo también la utilizo en mis proyectos propios como freelance.

¿Qué arquitectura utilizabamos antes?

Cuando llegué a mi empresa, hace 4 años, los proyectos principalmente eran web utilizando ASP.Net. Se estaban desarrollando siguiendo una arquitecura típica en 3 capas presentacion -> business -> data. Argumenté los problemas de este tipo de arquitecturas tradicionales enfocadas más en base de datos que al dominio. Me pidieron que pensara una nueva arquitectura para los proyectos así que propuse una arquitectura más orientada al dominio y siguiendo "más o menos" la estructura de capas que propone Erick Evans en su libro Domain-Driven Design:Tackling Complexity in the Heart of Software

Problemas de la arquitectura anterior

No me atrevería a decir que la estructura de capas que propone Erick Evans tiene problemas, lo que si puedo afirmar es lo que no funcionó en el equipo. En esta arquitectura dentro de la capa de aplicación se ubican los servicios, su función es coordinar los distintos objetos de la capa de dominio y de datos para llevar a cabo una acción. Su labor estaba clara que es coodinar, asimilamos "más o menos bien" que no debían contener lógica, esta debe residir en los objetos de dominio.

El problema vino a la hora de definir qué se representa como un servicio, acabamos definiendo servicios para todo, incluso había servicios invocando a servicios.

Como consecuencia el código no quedaba limpio y gente que entraba en el equipo no tenía claro cuando había que crear un servicio y el código legacy nuestro al que se enfrentaba tampoco ayudaba.

Era hora de buscar alternativas.

Conociendo Clean Architecture

Conocí Clean Architecture pero muy de refilón después de leer algunos artículos. No fue hasta que asistí a la Droidcon 2015 cuando escuché hablar más en profundidad a gente sobre esta arquitectura. En el mundo de Android se estaba convirtiendo prácticamente en un estándar en España.

De nuevo en mi empresa propuse cambiar de arquitectura con el objetivo de solventar los problemas que estábamos teniendo. Inicialmente mis compañeros no me miraron muy bien, comprensible después de lo que habia costado asimilar, aunque fuera con problemas, mi anterior propuesta.

Similitudes entre arquitecturas

Aplicar clean Architecture no fue tan difícil de asimilar por el equipo. Todas estas arquitecturas orientadas al dominio como la arquitectura de capas propuesta por Eric Evans, Clean Architecture de Uncle bob, Onion Architecture de Jeffrey Palermo tienen caracteristicas en común:

  • Independientes de Frameworks. No estan acopladas a librerias, lo que permite utilizar estas librerías como herramientas que son fácilmente sustituibles.

  • Testables. las reglas de negocio son fácilmente testables sin utilizar la interfaz de usuario, base de datos, servidor web.

  • Independientes de la interfaz de usuario. La interfaz de usuario es fácilmente modificable.

  • Independientes de la base de datos. Es fácil sustituir una base de datos por otra sin afectar a las reglas de negocio.

  • El dominio es la parte más importante la capa de dominio es la más importante y de la que dependen todas las demás pero el dominio no depende de ninguna. ¿como consigue el dominio comunicarse con las demás capas sin depender de ellas?, haciendo uso del principio SOLID de Inversión de dependencia. Escribí hace tiempo un artículo profundizando en este princpio.

Ventajas de Clean Architecture

En Clean Arquitecture los objetos encargados de la coordinación entre objetos de la capa de dominio y datos son los Use Case, también denominados Interactors. Esta definición esta más cercana la jerga funcional y se entiende mejor.

La principal difencia es que en Clean Architecture los objetos que coordinan (Use Case) se encuentran ubicados dentro de la capa de dominio y aquí si tienen una definición más concreta y clara. Por lo tanto un caso de uso se necesita cuando se tiene que coordinar una acción requerida por el usuario.
Nos resultó más fácil entender dentro de este marco cuando hay que crear un objeto que coordina y que no es lógico que un caso de uso invoque a otro, deben ser semánticos a acciones que puede hacer un usuario.

¿Sirve para todos los proyectos?

Supongo que para una aplicación muy muy sencilla puede que no, pero yo en mi experiencia con empresas nunca he hecho una aplicación sencilla. En ambito empresarial no se si encaja clean Architecture en todas las aplicaciones que existen, solo puedo decir que en las que yo he participado si.

El otro día leí un artículo que se titulaba Vísteme con Clean Architecture que tengo prisas, esa afirmación y el contenido del mismo definen bastante bien el valor que aporta esta Arquitectura y sus ventajas.

Conclusiones

Al final se trata de utilizar las herramientas en tu trabajo con las que te sientas más cómodo y sientas que haces tu trabajo mejor, de una forma más productiva. Eso es lo que me sucedió a mi y al equipo de mi empresa cuando aplicamos Clean Architecture en nuestros proyectos.

Código fuente

En mi GitHub tengo tres repositorios de ejemplo de Clean Architecture, en Swift para iOS y dos para Android, uno en java y otro en kotlin.

Los repositorios están pensados para refactorizar una app que no sigue buenas prácticas, no tiene tests, ni Clean Architecture.

La rama máster contiene la solución final y existe otras ramas en forma de Kata para evolucionar una parte de la app.

Artículos relacionados

Clean Architecture: Code Smells. Parte 1