Tiempo de lectura: 6 minutos

Vísteme con Clean Architecture que tengo prisas

Ayer tuve la ocasión de poder dar una charla sobre ‘Clean Architecture’ en Betabeers Salamanca.

No quería dar una charla más sobre en qué consiste la arquitectura propuesta por el Tío Bob pues creo que ya hay charlas muy interesantes sobre este tema. Así que decidí compartir cómo aplicamos esta arquitectura en un proyecto real donde se reflejara:

  • El porqué de aplicar ‘Clean’.
  • Contexto del proyecto.
  • Cómo se repartieron las tareas según el perfil del desarrollador.
  • Cómo fuimos desarrollando cada una de las capas.
  • Cómo definimos ‘los anillos’.

En resumen, quería darle un enfoque más orientado al cómo trabajamos con esta arquitectura.

Hasta que pueda hacerme con el vídeo, os describo cada una de las diapositivas de la presentación para que se pueda entender mejor. La presentación está al final de este post y en slideshare.

La presentación se puede dividir en tres bloques:

  1. Introducción a Arquitectura Clean.
  2. Definición de las capas en el proyecto.
  3. Desarrollo del código en cada una de las capas.

1. Introducción a Arquitectura Clean

Os dejo el enlace al artículo original o traducido al español que hizo Robert C. Martin sobre su Arquitectura Clean.

2. Definición de las capas en el proyecto

En este bloque de la presentación se explican cada una de las capas elegidas:

  • Capa ‘domain’. Es la capa más interna de nuestra arquitectura. No tendrá acceso directo al framework Android por lo que sólo tendremos código Java puro. El objetivo de esta capa es almacenar los casos de usos (interactors) y las entidades. Es la capa más importante de nuestra aplicación pues es la que define nuestro modelo de negocio.
  • Capa ‘presentation’: Es el anillo que envuelve el dominio y es la encargada de comunicar nuestro dominio con la capa de la UI. No dependerá del framework Android y sólo será Java puro. Además, contendrá los mappers que permitirán adaptar modelos de datos según la capa que los reciba. Ej: cuando se comunique con la capa interna, dominio, mapeará un modelo de dato externo a una entidad que es el único modelo de datos que entiende nuestro modelo de negocio. También mapeará una entidad a un modelo de datos exclusivo para la UI, Servicios, etc.
  • Capa ‘Framework’: Sería una capa dependiente del framework Android esta capa la dividimos en dos módulos dentro de nuestro proyecto:
    • ‘android’ donde estará el código de las vistas: actividades, fragmentos, custom views e inyección de dependencias o cualquier librería que dependa del framework.
    • data‘ donde estará la fuente de datos, de donde se obtendrá la información: base de datos, api, etc.

Cosas a destacar:

  • En el proyecto de datos usaremos varios modelos de datos:
    • Entidades: será exclusivo para el modelo de negocio.
    • Modelo de datos para la API: se crea un modelo de datos para el envío y la recepción de datos a través de la Api. Este modelo de datos usa la librería Gson para convertir los POJOS a Json y viceversa. Este ‘acoplamiento’ a la librería Gson nos hizo pensar en desarrollar un modelo de datos exclusivo para la Api.
    • Modelo de datos para la Base de Datos: Aquí nos pasa algo parecido a lo anterior. En el proyecto se usa OrmLite y se acopla al modelo a través de anotaciones. Es por eso que se tomó la decisión de crear un nuevo modelo de datos.
    • Modelo de Datos para la UI: Se crea un modelo de datos especial para la Interfaz de Usuario para convertir a la vista en algo sencillo y simple. Una vista sólo debe encargarse de mostrar la información tal cual viene. Cualquier tipo de operación no debe hacerse en la vista.
  • Inyección de dependencia a través de Dagger.

3. Desarrollo del código en cada una de las capas.

Como en la mayoría de los proyectos, no habíamos comenzado a desarrollar y ya llegábamos tarde. Se tenía que hacer una entrega visual y se descartó hacer una maqueta que pudiera ser “pan para hoy y hambre para mañana”.

El proyecto lo divido en cinco etapas:

  1. Etapa 1, Llegamos tarde. En esta etapa en donde decidimos meter Clean. La elección de Clean fue por:
    1. El proyecto se definió como algo pequeño en la fase inicial por lo que se esperaba que creciera.
    2. La API se estaba desarrollando a la vez que las aplicaciones móviles por lo que no queríamos desarrollar la parte de la comunicación con la Api pues sería un hacer/rehacer constante así que se necesitaba poder avanzar sin bloqueos.
    3. Poder testear aquellas partes que son más complicadas a fallo.
    4. Y lo más importante, crecimiento profesional 😉
  2. Etapa 2, Reparto de tareas. Había una fecha próxima de una entrega donde pudiera verse la interfaz y donde se permitían meter mocks. Así que en esta tapa se decidió realizar toda la parte de la Interfaz de Usuario y la capa de los ‘presenters’. La información que se muestra era obtenida a través de objetos fakes.
  3. Etapa 3, Matchball salvado. Una vez nos pusimos al día, se decidió desarrollar la capa de negocio y quitar los datos fake de los presentador. Ahora la información de mocks se obtenían de la capa data.
  4. Etapa 4, Api terminada. Una vez confirmado que la Api estaba terminada, decidimos quitar los mocks de la capa data e implementamos las distintas fuentes de datos. Aquí tengo que destacar que la obtención de datos de la Api se hacía a través de un Cliente local. Este cliente era el mismo que se usaba para la Api pero tenía la características de que los datos obtenidos eran de una carpeta local de nuestro proyecto. No quería depender de la conexión de red pues donde trabajamos salimos a través de un proxy y la red con la Ip pública va muy lenta.
  5. Etapa 5, Integrar todo. Una vez realizada toda la implementación, se cambio el cliente local por el cliente definitivo (es simplemente cambiar la concreción de la interfaz ‘Cliente’), se probaron los servicios web, se refactorizaron métodos, se crearon test, etc.

Os dejo aquí la presentación.


Y aquí el vídeo: