¿Se podría hablar de pragmatismo en la Arquitectura?
Recientemente he publicado una edición de Clean Architecture en iOS, "Principios y buenas prácticas de diseño aplicadas en iOS".
Ha sido un trabajo bastante gratificante porque me ha permitido consolidar y organizar la información obtenida a lo largo de la ejecución de múltiples proyectos en iOS en lo referente a las buenas prácticas y arquitecturas aplicadas.
En las soluciones móviles la arquitectura de referencia conocida como Clean Architecture ha sido asimilada bastante bien. No entraré a describir los detalles de las motivaciones por la cual se ha hecho tan importante este estilo de arquitectura en el diseño de las soluciones móviles, pero si quiero compartir un extracto de uno de los temas tratados en el libro:
¿Pragmatismo en la arquitectura?
Hay aspectos de la arquitectura que pueden ser negociables o en otros casos postergados. Sin
embargo hay otros aspectos de la arquitectura que no pueden ser omitidos y mucho menos ignorados.
En dichos términos, la arquitectura de la solución es pragmática sólo hasta cierto límite. Más allá, deja de ser Clean Architecture o en el peor de los casos, deja de ser arquitectura alguna.
Es la ponderación que un equipo debería manejar en aras de proteger la solución.
¿Cuáles podrían ser los aspectos no negociables en Clean Architecture?
En primer lugar, el gestor de inyección de dependencias.
Una solución robusta requiere necesariamente de un mecanismo que permita gestionar la inyección de dependencias para lograr la efectiva
aplicación de inversión de control. Este es un elemento que debe ser incluido desde la primera versión
de la aplicación.
En segundo lugar, se trata más bien de una definición en lugar de un componente y corresponde a
las tres capas que como mínimo deben estar presentes: Presentation, Data y Domain.
A partir de este
de mínimo de tres capas, la solución podría adicionar las que considere necesarias. En el capítulo
Organización del proyecto se discute las opciones para organizar dichas capas.
En tercer lugar, debe existir un patrón de diseño en la capa de presentación y un patrón de diseño
en la capa de datos. Para la capa de presentación hay varios candidatos (MVC, MVVM, MVP, MVI)
según se mostró en el capítulo de patrones.
En la capa de datos definitivamente es recomendado el patrón Repository. Algunas implementaciones podrían proponer usar un Datasource directamente, sin embargo en Clean Architecture no es
negociable dicha delegación, Repository debe estar presente.
En cuarto lugar, un componente que podría generar polémica por tratarse de un componente
mediador (al igual que Repository), se trata de UseCase. Algunos lo omitirían para integrar el
repositorio directamente con el ViewModel pero en Clean Architecture este componente no es
negociable. Es una pieza clave en el diseño. En algunas implementaciones prefieren llamarlo
Interactor.
Y en quinto lugar se encuentra una configuración que también debe estar incluida desde el inicio
de la aplicación. Es la configuración aplicada por el patrón Plugin para administrar las variantes de
la solución. Estas mismas configuraciones son las usadas por el sistema de procesos e integración
continua.
¿Cuáles son los aspectos que podrían ser negociables?
A través de refactoring y en la medida que la solución lo requiera, podría incluirse nuevas
capacidades para robustecer la aplicación, optimizar procesos y mejorar atributos de calidad de la
solución.
Los Mappers. Incluir una estrategia de mappers como se describe en la sección Mapeo entre fronteras
conlleva a múltiples beneficios en la comunicación entre las capas y el transporte de información.
Una estrategia de caché. Si bien la implementación de la aplicación puede iniciar sin una estrategia
para gestionar la información local y la información remota, es adecuado incorporar en una etapa
temprana un mecanismo que permita incorporar los beneficios de un diseño offline mode. Esta
capacidad podría mejorar atributos de calidad tales como performance y disponibilidad. El capítulo
Estrategias para administrar información local y remota es dedicado totalmente a este tema.
Otro conjunto de componentes que podrían agregar flexibilidad en la aplicación de lógica de
aplicación o presentación son los Value Objects. Este patrón puede ser agregado en una etapa
posterior en aquellas funcionalidades que contienen un complejo conjunto de reglas de negocios
y validaciones. Un mayor detalle es presentado en la sección Cuando decidir entre Entities o Value
Objects.
Y por último pero no menos importante, el patrón Coordinator, el cual bajo criterio propio (en mi
opinión) debería estar incluido desde la versión inicial de la aplicación. Es una mejora que aumenta la
testabilidad de las Vistas y los flujos de navegación entre ellas. También proporciona la flexibilidad
de configurar los flujos de navegación facilitando por ejemplo el AB Testing. La descripción y
aplicación del patrón se encuentra en Coordinator.
ConversionConversion EmoticonEmoticon