Índice
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
Entitiesque leyera, oEnterprise Bussiness Rulesseguí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):
- Enterprise Business Rules
- Application Business Rules
- Interface Adapters
- 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 uninterface.El controller en este caso forma parte de Application Business Rules
-
Un
ApiControllerusará los servicios.Forma parte de Interface Adapters
Pero nunca al revés, desde dentro hacia afuera:
- En una
data classnunca se utilizará uncontrollero 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:
Top comments (0)