Exploramos en pocos párrafos todo lo que necesitás saber para que la próxima vez que diseñes una app lo hagas al estilo world class. Además, analizamos una clave: el rol de los tomadores de decisiones en una empresa.
El momento de decidir el tipo de arquitectura mobile a seguir para desarrollar una app es el punto más decisivo de todo el proyecto. Es elegir un camino que puede llevarte al éxito o que puede hacer que dejes todo y vuelvas a empezar un trabajo que te llevó meses. Ir por una ruta u otra no solo involucra a los desarrolladores de un equipo sino también a los tomadores de decisión de una empresa.
¿Qué pasa cuando a los developers ya no les alcanza la arquitectura mobile que les brindan Google y Apple? ¿Cómo hacer cuando hay que escalar apps con esa arquitectura para que sea utilizada por millones de usuarios? ¿Y si tenés que pensar un app que va a ser desarrollada por decenas de desarrolladores? En este artículo, vamos a develar esas y más preguntas y a charlar sobre cómo las teorías de software pueden ser aplicadas en arquitectura mobile.
¿Quién es quién?: un breve repaso por las arquitecturas mobile
iOS y Android tienen un historial interesante de arquitecturas mobile:
- MVC, una de las más antiguas de todas, debe su nombre a Model — View — Controller. El problema con este enfoque fue que, en verdad, Apple y Google siguen sus propios patrones en términos de ese sistema (Modelo — Vista — Controlador) y esta no terminó siendo la mejor opción.
- Entonces apareció un nuevo patrón: MVVM. Acá las siglas responden a Model-View-ViewModel, y representan a sus componentes. En iOS fue un avance porque el patrón de distribución era mejor que el de la arquitectura anterior. En Android, los principales problemas se dan cuando las aplicaciones aumentan su complejidad. Los problemas de esta arquitectura son principalmente dos. Uno es que pone el foco en mostrar la información en pantallas y su relación, y no tanto en el lugar que ocupa la lógica de la app y los datos que la nutren. El otro gran problema es que no tiene criterios de negocio, no hay claridad sobre la organización de los componentes y la estructura de sus relaciones, y esto se complica cada vez más a medida que crece la necesidad de escalar.
- Como MVVM no terminaba de cerrar, apareció un nuevo patrón de arquitectura mobile: VIPER (View, Interactor, Presenter, Entity y Router). Al principio, fue obra más que nada de desarrolladores de iOS, aunque poco a poco fue marcando su paso en Android. Esos devs se encontraron con un enfoque de arquitectura limpia, y vieron en él la posibilidad de dividir la estructura lógica de la app en distintas capas o niveles de responsabilidad (más adelante vamos a profundizar en esto). De este modo, no hay problemas de dependencia y se potencia la posibilidad de hacer pruebas. Sin embargo, este modelo, no es del todo recomendable porque no es tan conocido y es más que nada utilizado en iOS. Por ende, no permite lograr una arquitectura común tanto para Android como para iOS.
La teoría del software aplicada a la arquitectura mobile
Como dijimos al principio, llega un punto en el que Google y Apple, con sus arquitecturas mobile (que, hay que reconocer, permiten un desarrollo rápido de apps simples), no dan suficiente soporte para escalar. Entonces, al momento de empezar, hay que pensar cómo hacés algo que cualquiera pueda utilizar dentro de esas plataformas y que ese algo, pueda escalar a millones de usuarios en un futuro.
Cuando miramos por sobre las arquitecturas mobile que nos dan Google y Apple, es necesario replantearse la manera en la que encaramos los proyectos desde el principio. Al menos para conocer todas las opciones que tenemos de antemano.
Marco Scabbiolo, referente mobile en redbee, nos contó algunas teorías clave que hay que tener en el mapa al momento de comenzar un proyecto. Una de ellas es DDD (Domain Driven Design). “Esta dice que primero tenés que organizar las cosas por tu dominio, producto o negocio y después por la estructura”, cuenta Marco.
Es decir, se puede dividir en elementos estructurales como “dominio usuario”, “dominio registro”, “dominio búsqueda” y “dominio pago”. Esto facilita que, cuando se necesite, se ubique. “Podés tener todo independiente en módulos distintos acoplables en cualquier app. Eso te da la flexibilidad de poder armar con esos módulos otras apps”, agrega sobre los beneficios de seguir los principios de esta teoría.
La otra teoría que nos trae nuestro desarrollador es Clean (algo charlamos sobre ella). En esta (que según Marco cualquier arquitectura buena debería seguir), hay algo esencial: se tienen que poder organizar las partes para que no haya acoplamiento, es decir, que todas las partes no estén relacionadas entre sí.
La arquitectura hexagonal es una rama de Clean, y acá las partes que hacen a la app tienen que poder ser reemplazables en cualquier momento. “Hay tres capas: data — que es cómo obtengo la información-, aplicación -que tiene la lógica real de lo que hace la app-, y presentación -que es la capa que se centra en la interfaz y cómo se muestra al usuario-”, dice nuestro desarrollador.
La gran mayoría de las apps sigue esta tríada, aunque puede haber algunas variantes. La clave es que sean reemplazables y estén bien delineadas y considerar adoptar esta teoría desde el principio, antes de que sea muy tarde para hacerlo.
¿Cómo se puede aplicar la arquitectura hexagonal?
Una empresa latinoamericana de retail (cliente de redbee) buscaba crear una app con varias versiones adaptables a usuarios finales y vendedores. “Se trataba de poder armar microproductos más dedicados a cada cliente o retail con diferentes funcionalidades”, recuerda Marco.
“Se propuso armar los módulos y que a cada cliente le pudieran dar los módulos que quisieran con un costo técnico mínimo y libertad para hacer la oferta de marketing del retail final”, agrega nuestro entrevistado. En este sentido, fueron por la arquitectura hexagonal para poder pensar una división entre partes de negocios, una arquitectura flexible que se fuera adaptando a la evolución de la app y con partes desacopladas.
¿Quién toma las decisiones de arquitectura mobile?
Al momento de decidir qué teoría y arquitectura mobile seguir, cliente, líderes del proyecto y equipos de desarrollo tienen que estar en la misma página de lo que esto significa. Si se elige invertir tiempo y dinero en una app simple y rápida que después no pueda escalar, esto significará pérdida de tiempo y dinero a futuro.
“La idea es que tu propio equipo también crezca y acompañe el crecimiento de la app”, reflexiona Marco, sobre el desafío de las empresas más grandes para armar un equipo de desarrollo in-house sólido. De otra manera, “se hace una brecha entre el crecimiento orgánico que debería haber tenido el equipo y al que escala el producto”, agrega.
El desafío es pensar a la arquitectura más allá de la plataforma. “Si planteás una arquitectura base que aplica a cualquiera tecnología, es más fácil hacer la rotación a cualquiera otra tecnología. Si hay una única arquitectura para las dos (iOS y Android), también podés migrar más fácil de una a la otra”, cierra.
Y entonces, ¿qué arquitectura es mejor?
Sobre todo cuando llega el momento de escalar una app, nuestro desarrollador recomienda MVVMSR (Model, View, View-Model, Service, Repository). “Esta es una revisión del MVVM tradicional incorporando DDD y Clean (hexagonal)”, explica Marco. En esta arquitectura, cada dominio está delineado y tiene una responsabilidad particular, aunque pueden existir dependencias entre ellos. Además, pueden combinarse para generar una aplicación puntual solo con las funciones que se necesitan.
“Los dominios internamente incorporan una arquitectura hexagonal dividiendo sus componentes en Presentación (View, View-Model), Aplicación, (Model, Service) y Data (Repository)”, suma nuestro desarrollador.
Estos párrafos resumen bastante nuestro enfoque de trabajo en redbee. No solo tenemos en claro que es necesario apoyar a nuestros clientes en proyectos desafiantes incorporando tecnología que les aporte un valor extra, sino que además y sobre todo, nos aseguramos que ese crecimiento que queremos en nuestros clientes, también esté presente fuertemente en nuestros equipos.
