¿Qué es Clean Architecture?

Los términos Clean Architecture y Clean Code hacen referencia a buenas prácticas de diseño de arquitectura y programación que se aplican sobre ciertos elementos. Clean Architecture Clean Code Como parte de su filosofía, Clean Code busca que el código sea lo más limpio posible. Para lograrlo, existen recomendaciones que van desde cómo se nombran las variables, la forma como se construyen funciones o se comenta el código y la alineación o la abstracción de objetos y estructuras, entre otros. Todo esto, con el fin de hacer el código mucho más entendible en el presente y futuro, testeable y fácil de integrar. ¿Qué es Clean Architecture? En esta ocasión hablaremos sobre Clean en la arquitectura de software, especialmente en Android. El principal objetivo de una arquitectura limpia es la capacidad de separar el código en sus diferentes responsabilidades. ¿Recuerdas las 3 capas básicas del modelo de capas que presenté anteriormente? Presentation Layer. Business Logic Layer. Data Layer. Estas son las tres responsabilidades base sobre las cuales trabaja la arquitectura limpia. Clean Architecture es un término introducido por Rober C. Martin, mejor conocido como Uncle Bob o Tío Bob. Él recopiló los modelos de capas más utilizados en una versión mejorada a la que llamó Clean Architecture. A continuación, presento 5 principios sobre los cuales se basó: Es independiente de cualquier framework. La arquitectura limpia debe ser capaz de aplicarse a cualquier sistema sin importar el lenguaje de programación o las librerías que utilice. Las capas deben quedar tan bien separadas que puedan sobrevivir individualmente, sin necesidad de externos. Testeable. Entre más pura sea una función, clase o módulo más fácil será predecir el resultado a obtener. Cuando hablamos de que algo sea puro nos referimos a que no tenga efectos colaterales. Lee este artículo para que entiendas mucho más sobre los efectos colaterales y funciones puras. (Importante leerlo para completar la lección). Cada módulo, tanto de UI, base de datos, conexión a API Rest, etc., se debe poder testear de forma individual. Independiente de la interfaz de usuario (UI). Uno de los componentes que sufren cambios constantemente es la interfaz de usuario. La UI debe ser capaz de cambiar sin alterar todo el sistema y, si vamos más allá, esta capa debería vivir tan independiente que podría ser desensamblada y sustituida por otra. Por ejemplo, cambiar una UI Móvil por una en modo consola. Independiente de la base de datos. Así como en el punto anterior, esta capa debe ser tan modular que sea posible agregarle múltiples fuentes de datos, e incluso múltiples fuentes del mismo tipo de datos. Por ejemplo, manejar varias bases de datos como MySQL, PostgreSQL, Redis, etc. Independiente de cualquier elemento externo. Si en algún punto nuestro sistema necesita de una librería, otro sistema o cualquier elemento a conectar, debería ser fácilmente ensamblado y también debería ser modularizado. De hecho, para el sistema esta capa externa debería ser transparente. Estos principios fueron graficados por el Tío Bob en el siguiente diagrama: Y si quisiéramos hacer encajar las tres capas que mencionamos antes, se vería así: El nivel de acceso se dará a partir de las capas externas hasta llegar a las internas, como se muestra a continuación: Ahora, expliquemos cada elemento Entities. Las entidades son los modelos definidos que interactuarán en el sistema. Estas deben ser lo suficientemente abstractas para ser usadas por múltiples aplicaciones en el negocio. Use Cases (casos de uso). Contienen las reglas que le dan sentido a la aplicación. Los casos de uso dirigen el flujo a las entidades y las orquestan para cumplir con el negocio. Repositories y Presenters. Interface Adapters. Esta es la capa intercesora que convierte los datos extraídos por la interfaz de usuario y la capa de datos en el formato más conveniente para los casos de uso. UI y Data Source. Frameworks y Drivers. En esta capa van todos los detalles, tanto para mostrar datos en la UI como para obtener los datos requeridos.