# Clean Architecture

_Clean Architecture_ es un nombre popularizado por [Robert Cecil Martin](https://en.wikipedia.org/wiki/Robert_C._Martin), que se basa en la premisa de estructurar el código en capas contiguas, es decir, que solo tienen comunicación con las capas que están inmediatamente a sus lados.  La idea es que cada nivel debe realizar sus propias tareas y se comunica únicamente con sus niveles inmediatamente contiguos.

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.

El principal objetivo de una arquitectura limpia es la capacidad de separar el código en sus diferentes responsabilidades.

<figure><img src="https://624742151-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFRKN8coRWwuuSr24p99X%2Fuploads%2Fmj4nkNzLFmrYF5qYu7Hk%2Fimage.png?alt=media&#x26;token=867678c3-5d86-4896-b90c-165cb5e41edc" alt=""><figcaption><p>Imagen de <a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html">Robert C. Martin</a></p></figcaption></figure>

#### **1. 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.

#### **2. 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.

#### **3. 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, también esta capa se encuentran los controladores, los presentadores y lo modelos de vista. Acá podríamos tener todo el patrón MVC.

#### **4. 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.

Tambien podríamos hacer coincidir el modelo básico de capas que consiste en&#x20;

* Presentation Layer
* Business Logic Layer
* Data Layer

<figure><img src="https://624742151-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFRKN8coRWwuuSr24p99X%2Fuploads%2FwUD85zyjIDGT0cX0K1a3%2Fimage.png?alt=media&#x26;token=d014c92f-4a37-4c8b-9088-91a76c751967" alt=""><figcaption></figcaption></figure>

### Principios de Clean Architecture o 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ó:

#### **1. 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.

#### **2. 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. Cada módulo, tanto de UI, base de datos, conexión a API Rest, etc., se debe poder testear de forma individual.

#### **3. 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.

#### **4. 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.

#### **5. 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.

