Arquitectura Limpia

Índice

• Introducción
• Tipos
• Estructura
  • Enterprise Business Rules
  • Application Business Rules
  • Interface Adapters
  • Frameworks and Drivers
• Regla de la dependencia
• 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:

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.

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: