Cuando estamos en el proceso de planificar el desarrollo de una nueva aplicación generalmente no pensamos en la arquitectura y simplemente vamos a codificar guiados por algunas maquetas o una lista de requisitos genéricos, seamos claros, esta práctica es más común que pensamos, también estamos mentalmente bloqueados por la idea de ser ágiles (ignorando que ágil no significa rápido) y nos saltamos el paso de diseñar a nivel arquitectónico nuestras apps.
Si no declaramos que la arquitectura es importante desde el principio, el costo de mantenimiento aumentará y eventualmente pasaremos más horas desarrollando una nueva característica o, lo que es peor, una simple tarea de cambiar una parte de nuestro sistema podría ser un problema (desorden) para desarrollar.
Aplicar Clean Architecture en desarrollo de aplicaciones con Xamarin
En este artículo, veremos cómo Clean Architecture podría ayudarnos a organizar y estructurar nuestros proyectos de Xamarin, utilizando algunas referencias del famoso libro Clean Architecture: A Craftsman’s Guide to Software Structure and Design de Robert C. Martin (también conocido como Tío Bob) en el que dice:
«La arquitectura de un sistema de software es la forma dada a ese sistema por quienes lo construyen. Dicha forma está en la división de ese sistema en componentes, la disposición de esos componentes y la manera en que esos componentes se comunican con entre sí. El propósito de esa estructura es facilitar el desarrollo, despliegue, operación y mantenimiento del sistema de software que contiene «.
Clean Architecture tiene un objetivo principal, que es la separación de preocupaciones, esta separación se realiza dividiendo el software en capas. En la forma más simple, nuestra arquitectura debe tener al menos una capa para las reglas de negocio y otra capa para las interfaces de usuario y sistema.
Sistemas en Clean Architecture
Este tipo de arquitectura produce sistemas con las siguientes características (extraídas del libro del tío Bob):
Independiente de frameworks
La arquitectura no depende de la existencia de alguna librería ni framework especifico. Esto le permite utilizar dichos frameworks como herramientas, en lugar de obligarnos a ajustar nuestro sistema a sus limitaciones.
Capacidad de hacer tests
Las reglas de negocio (a través de casos de uso) se pueden probar sin la interfaz de usuario, la base de datos, el servidor web o cualquier otro elemento externo.
Independiente de la interfaz de usuario
La interfaz de usuario puede cambiar fácilmente, sin cambiar el resto del sistema. Una interfaz de usuario de Xamarin podría reemplazarse por una interfaz de usuario de consola o una web app, por ejemplo, sin cambiar las reglas de negocio.
Independiente de la fuente de datos
Podríamos cambiar SQLite o Realm por CosmosDB u otra cosa sin muchos inconvenientes. Nuestras reglas no están vinculadas a la base de datos.
Independiente de cualquier servicio externo
De hecho, las reglas de su negocio no saben nada sobre las implementaciones de interfaces con el mundo exterior.
Capas en Clean Architecture, a continuación las definimos.
Capas en Clean Architecture
- Presentation: capa que contiene las interfaces de usuario.
- Framework: implementa las interacciones con SDKs específicos de la plataforma y librerías externas, también proporciona implementaciones concretas de la capa de datos.
- Use cases: contiene reglas de negocio específicas de nuestra aplicación. Encapsula e implementa todos los casos de uso del sistema.
- Domain: contiene las entidades que representan objetos de negocio, estos objetos pueden tener métodos (Reglas Comerciales Críticas) o puede ser un conjunto de plain objects.
- Data Interfaces: interfaces con la definición de todas las fuentes de datos, se implementan en la capa de Framework.
- Repositories: contiene los repositorios, utilizan las interfaces de datos para recuperar información externa.
- Tests: pruebas unitarias que apuntan a los casos de uso.
La regla de oro que hace que esta arquitectura funcione es la Regla de Dependencia:
«Las dependencias del código fuente deben apuntar solo hacia adentro, hacia políticas de nivel superior».
Dicho esto, nada en un círculo interno conoce sobre algo en un círculo externo.
Para mantener un enfoque simple, vamos a agrupar las capas en App (círculos amarillos), Core (círculos grises) y Tests (círculos rojos).
Analicemos esto con una aplicación con un solo caso de uso: obtener pedidos para el usuario actual.
Así es como se ve en un proyecto Xamarin Forms:
Capa de Aplicación
Capa Core
Capa de tests
Como se puede ver, todo comienza en la interfaz de usuario, cuando el usuario abre la aplicación, muestra el MainPage.xaml de Orders, esta vista tiene un Binding Context conectado al MainPageViewModel que llama al caso de uso correspondiente para obtener la lista de pedidos y mostrarlos al usuario.
La conexión entre el caso de uso y todas las dependencias necesarias se realiza mediante Unity (usando Prism) en la capa de aplicación, siguiendo la Regla de Dependencia, es algo como esto:
El resultado final del flujo es esta pantalla:
Si deseas examinar todo el código, puede consultar el proyecto en GitHub.
En conclusión (sí, otra referencia del tío Bob):
Su arquitectura debe informar a los lectores sobre el sistema, no sobre los frameworks que utilizó en su sistema. Si está construyendo un sistema de atención médica, cuando los nuevos programadores miran el código fuente, su primera impresión debería ser: «Oh, este es un sistema de atención médica». Esos nuevos programadores deberían poder aprender todos los casos de uso del sistema, y aún así no saber cómo se ve (a nivel de interfaz de usuario) el sistema.
¿Quieres más información sobre nuestros servicios de desarrollo de aplicaciones móviles?
Contacta con nuestro equipo de Mobile
