Arquitectura Limpia
Tags: architecture, programming, learning
Published: 2023-10-15 09:50:23

## Índice

- [Introducción](#introducción)
- [Tipos](#tipos)
- [Estructura](#estructura)
  - [Enterprise Business Rules](#enterprise-business-rules)
  - [Application Business Rules](#application-business-rules)
  - [Interface Adapters](#interface-adapters)
  - [Frameworks and Drivers](#frameworks-and-drivers)
- [Regla de la dependencia](#regla-de-la-dependencia)
- [Diagrama desglosado](#diagrama-desglosado)

-----

## Introducción

En este post no voy a explicar para que utilizar la Arquitectura Limpia, ni que ventajas tiene ni las características. 

Lo que sí voy a explicar es **como utilizarlo** y que contiene cada capa. 

Lo que pretendo es que tú como lector no tengas que recurrir a tantas fuentes como yo para saber poner en práctica el concepto, que en última instancia, es lo más importante sobre este tema.

## Tipos

Seguramente te suenen cosas como **DDD**, **Arquitectura Hexagonal**, **Arquitectura Onion**, etc.

Todos estos ejemplos tienen que ver en como estructurar el código de nuestros programas. Son distintos tipos de arquitecturas de software. 

El problema que yo he encontrado a medida que aprendía sobre el tema, es que, en multitud de ocasiones se explica de forma muy general los conceptos _(definiciones muy de Wikipedia)_, en otras ocasiones me he encontrado que se mezclan términos de una arquitectura a otra o se cambia el nombre de las cosas y todos estos hechos al final confunden mucho.

Dicho esto, yo explicaré solamente **Clean Architecture** propuesto por **Robert C. Martin** _(el Tío Bob)_. Como es la **estructura**, que **contiene cada capa** y poniendo algunos **ejemplos reales** para cada capa. También he desglosado el gráfico para hacerlo como una especie de cheatsheet que está al final del artículo.

## Estructura

El modelo propuesto por el tío Bob imagino que lo habrás visto en multitud de ocasiones y también todas sus variaciones *(al final todas las arquitecturas tienen similitudes)* y es el que tenemos en la siguiente imagen:

![Arquitectura Limpia Robert C. Martin](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/edte5qwmp5dj1j9qfiou.png)

Yo cuando veía esta imagen aun conociendo Clean Architecture me costaba entenderla y dependiendo del stack que utilices puedes entenderla aún menos.

Los nombres reales de cada círculo o capa son los de la leyenda de la derecha y no lo que hay en cada círculo 💥.

> Yo no entendía que era que, por muchas definiciones de `Entities` que leyera, o `Enterprise Bussiness Rules` seguía sin comprenderlo porque todo el mundo usa la misma definición.

Es decir, que lo que está escrito dentro de los círculos son simplemente ejemplos *(lo menciono por si a alguien le ha pasado como a mí)*.

La estructura es la siguiente *(desde dentro hacia afuera)*:

1. **Enterprise Business Rules**
2. **Application Business Rules**
3. **Interface Adapters**
4. **Frameworks and Drivers**

Perfecto! no se entiende nada o muy poco.

### Enterprise Business Rules

En este círculo vas a almacenar cosas como: 

- `interface` *(typescript)* 
- `data class` *(kotlin)*
- `record` *(c#)*
- `record` *(java)*

Te habrás dado cuenta de que solamente se engloban **clases de datos** o en algún casual una clase con atributos y métodos, pero que **no salga al exterior**.

Que no salga al exterior quiere decir que no deberá utilizar cosas como la base de datos, APIs o cualquier otra conexión con elementos externos.

Estas clases solo se conocen a ellas mismas, son como Narciso, no ven más allá de su ombligo.

### Application Business Rules

En este círculo guardarás el **código relacionado con la aplicación**, API, web o lo que sea que programes.

- Si mi aplicación cuenta con un **carrito de compra**, aquí harás las **operaciones** **necesarias** con el **carrito de compra**.

- Si mi backend debe **generar** un **PDF** lo harás aquí.

- Si la app calcula cuantos coches pueden entrar en un aparcamiento *(todavía inexistente el aparcamiento)* conociendo los m² del aparcamiento, el **cálculo** lo **harás** **aquí**.

Algunos ejemplos concretos de que deberás englobar aquí son los siguientes:

- `controllers` *(expressjs)*
- `service` *(java spring boot)*
- Servicios *(.net)*
- `Injectable` *(nestjs)*

> En muchos programas las 2 capas internas (Enterprise Business Rules y Application Business Rules) se engloban en una única que la llaman Dominio o Domain.

> El nombre se refiere al núcleo del negocio o al propósito principal de la aplicación.

### Interface Adapters 

Este círculo funciona como **puente entre el anterior y el siguiente**.

El círculo contendrá cosas como:

- `router` *(expressjs)*
- `controller` *(java spring boot)*
- `ApiController` *(.net)*
- `controller` *(nestjs)*

También se utilizarán los **repositorios** inyectándolos por ejemplo en los **controladores** o **servicios**, así el controlador/servicio podrá utilizar la base de datos pero no directamente. O podrá hacer peticiones a una API externa.

#### Disclaimer ⚠

Como harás observado en **ExpressJS** existen **Controllers y Routers** y en los demás framworks a estos elementos se les llama **Servicios y Controllers**, pero vienen a ser lo mismo con distintos nombres.

| ExpressJS  | Spring Boot | .Net          | NestJS      |
| ---------- | ----------- | ------------- | ----------- |
| Controller | Service     | Servicios     | Injectables |
| Router     | Controller  | ApiController | Controller  |

### Frameworks and Drivers
Este puede llegar a ser algo confuso, ya que engloba cosas como la base de datos y la web y esto es raro porque al verlo así, en nuestra cabeza ponemos en el mismo nivel el código de la base de datos y el de la web.

Aquí guardarás cosas como los DTOs, las consultas a base de datos, las tablas, el cliente web.

## Regla de la dependencia

Una vez entendemos la estructura debemos entender como usar los elementos entre sí. Para utilizar de forma correcta cada elemento **siempre nos guiaremos por la Regla de la Dependencia**.

Y esta regla en esencia es que los elementos del interior se conocen solamente a ellos mismos y a nadie de fuera.

Es decir, que los círculos de fuera siempre van a conocer *(y usar)* a los de dentro y nunca al revés.

Por lo tanto, podemos afirmar:

- Las **consultas a bases de datos** pueden hacer uso de un `data class`.
> Ya que se encuentran en Frameworks & Drivers

- Un `controller` *(expressjs)* puede usar un `interface`.
> El controller en este caso forma parte de Application Business Rules

- Un `ApiController` usará los servicios.
> Forma parte de Interface Adapters

Pero nunca al revés, desde dentro hacia afuera:

- En una `data class` **nunca** se utilizará un `controller` o la base de datos.

## Diagrama desglosado

Comprendiendo lo anterior he intentado desglosar el gráfico y hacerlo más entendible para mí con la esperanza de que para ti también sea más entendible:

![Diagrama Clean Architecture Desglosado CheatSheet](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lf9n3ibw4cvcngbur8kp.png)