Clean Architecture

Cualquier persona que haya trabajado como desarrollador durante, al menos, unos meses probablemente se ha enfrentado a situaciones en las que la aplicación en la que estaba trabajando, que al principio era amigable y estructurada, ha crecido tanto y tan rápido que contiene clases de más de 800 líneas de código. En ellas se pueden encontrar elementos duplicados, métodos que realizan quince acciones diferentes y poco a poco van surgiendo dificultades para encontrar dónde se realizan determinadas acciones o incluso para realizar tareas que deberían ser triviales como crear test unitarios.

Plantear una nueva funcionalidad o una ampliación de las ya existentes empieza a ser inviable sin la perspectiva de invertir tiempo en refactorizar, y es en este momento en el cual empiezan a surgir incógnitas como: ¿qué ha pasado con mi proyecto?, ¿cómo hemos podido llegar a esta situación?

Modelo-Vista-Controlador

Tras enfrentarnos a este problema, probablemente empecemos a investigar sobre arquitectura de software o hablemos con developers desarrolladores experimentados. En ese camino, lo más probable, es que nos acabemos encontrando con las famosas siglas MVC. Si, ( M odelo M odel- V iewsta- C ontrolador C ontroller), vamos a intentar entenderlas:

ModeloModel : son las clases que definen los datos de nuestra aplicación.

VistaView : es la interfaz propiamente dicha en definitiva el punto de entrada del usuario a nuestro productoa aplicación.

ControladorController : donde son las clases en las que se van a realizar vamosl a capturar de los eventos que suceden en la interfaz actuando en consecuencia. Además, es dondede realizarse las interaccionesaremos con el modelo de la aplicación.

Esta sencilla arquitectura no es la solución a todos nuestros problemas ya que si se aplica en sentido literal pueden aparecer dificultades. En pocas semanas los controladores que venían con la promesa de solucionar nuestros problemas serán clases de miles de líneas que además de responder a eventos de la interfaz, realizarán llamadas a servicios web, obtendrán y almacenarán información en BBDD, realizarán validaciones, aplicarán reglas de negocio, y todo esto etcentre otras muchas tareas. FY finalmente, habremos implantado una arquitectura M assive- V iew- C ontroller M assive- V iew- C ontroller, ya que ahora tendremos controladores que tendrán los mismos problemas que pretendíamos solucionar al principio.

Un poco de reflexión

Ahora que parece que tenemos claro que existe un problema vamos a plantear unas sencillas preguntas, sobre situaciones del día a día:

¿Pondríais en vuestra cocina el armario de la ropa?

¿Pondrías la ducha en el recibidor?

¿Tendríais la tv colgada encima de la vitro y la campana extractora de humos encima del sofá?

Lo lógico tras estas preguntas es que penséis que me estoy equivocando de artículo, pero… ¿por qué si os escandalizan esas asunciones sobre la distribución del hogar, os parece lógico realizar llamadas a servicios web en el mismo fichero que capturáis los eventos que suceden en la interfaz? Desde un punto de vista de ingeniería del software es tan extraño como cualquiera de las anteriores preguntas.

Clean Architecure al rescate

Clean Architecture es un nombre popularizado por Robert Cecil Martin , conocido como “‘Uncle Bobb’”, que se basae en la premisa de estructurar el código en capas contiguas, que es decir, que solo tienen comunicación con las capas que están inmediatamente a sus lados. Basados en esta idea podemos encontrar artículos que hablan sobre Clean Architecture , Onion Architecture , Hexagonal Architecture , todas ellas stas arquitecturas tienen diferentes enfoques, pero todas ellas tienen en comúncomparten la idea de que cada nivel debe realizarce sus propias tareas y se comunique comunica únicamente con sus niveles inmediatamente contiguos.

Los niveles de los que se compone Clean Architecture son los siguientes:

UI : la interfaz de usuario propiamente dicha (html, xml, etc, etc…).

ControllersPresenters : clases que se subscriben a los eventos generados por la interfaz y que responden en consecuencia, también realizan el pintado de la información en la interfaz.

Use Cases : evaluación de reglas de negocio y tomas de decisiones.

Entities : modelo de datos de la aplicación, comunicación con servicios web, cache de datos.

Este es el gráfico tradicional original que proponeuso el Uncle Bob y se puede apreciar como los diferentes niveles anteriormente descritos sólo se comunican con los inmediatamente contiguos.

A continuación, tenemos otra interpretación del gráfico tradicional, en la que se han añadido descripción de las tareas que se suelen realizar en cada uno de los niveles.

Cada uno de los niveles aquí representados podría considerarse dentro de la estructura de nuestra aplicación como carpetas independientes, diferentes módulos o librerías que se incluyen como dependencias del proyecto principal o incluso podríamos aplicar este tipo de estructuración sin la necesidad de reflejarlo de forma explícita en la estructura del proyecto.

Ahora que conocemos los fundamentos básicos de Clean Architecture, vamos a ver cuáles son algunas de las ventajas e inconvenientes a las que nos enfrentaremos si decidimos aplicar esta metodología de trabajo en nuestro proyecto.

Ventajas

Independencia : cada capa tiene su propio paradigma o modelo arquitectónico como si se tratara de una aplicación en si misma sin afectar al resto de los niveles.

Estructuración : mejor organización del código, facilitando la búsqueda de funcionalidades y navegación por el mismo.

Desacoplamiento : cada capa es independiente de las demás por lo que podríamos reemplazarla o incluso desarrollar en diferentes tecnologías. Además de reutilizar alguna de ellas en diferentes proyectos.

Facilidad de testeo : podremos realizar test unitarios de cada una de las capas y test de integración de las diferentes capas entre sí, pudiendo reemplazarlas por objectos mock temporales que simulen su comportamiento de forma sencilla.

Desventajas

Metodología : todo el equipo de desarrollo debe conocer la metodología que se está aplicando y cada desarrollador debe ser responsable de entender y aplicar las reglas establecidas a medida que está desarrollando.

Complejidad : la velocidad de desarrollo al comienzo del proyecto es menor debido a que hay que establecer esta estructura y todo el equipo debe adaptarse a la nueva forma de trabajar, pero poco a poco y a medida que la aplicación va creciendo el mantenimiento y ampliación será más sencillo.

Abimael Barea