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?
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, ( ModeloModel-Viewsta-ControladorController), vamos a intentar entenderlas:
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 Massive-View-ControllerMassive-View-Controller, ya que ahora tendremos controladores que tendrán los mismos problemas que pretendíamos solucionar al principio.
Ahora que parece que tenemos claro que existe un problema vamos a plantear unas sencillas preguntas, sobre situaciones del día a día:
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 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:
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.
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
La certificación tipo es un procedimiento reconoc...
La gestión de riesgos es hoy crítica para la fij...
Si piensas en productos de consumo, es probable qu...
