Patrones de arquitecturas en aplicaciones Móviles

Good Judgement is usually the result of Experience. And experience is frequently the result of bad judgement. But to learn from experience of others requires those who have the experience to share the knowledge with those who follow.

-Benjamin Franklin

Durante ya bastante tiempo he estado interesada en aprender los diferentes patrones de arquitectura que se pueden implementar en el desarrollo de aplicaciones móviles tanto en Android como en iOS en saber cómo estas decisiones afectan en la velocidad del desarrollo, en la dificultad de mantenimiento. La eficacia en la reutilización de código y la facilidad de aprenderlas.

¿Pero qué es un arquitectura de Software?

Sistemas de software son construidos para satisfacer las necesidades del negocio, y la arquitectura es ese puente que une esas metas a veces muy abstractas del negocio con el resultado concreto final que es el sistema. Mientras que el camino de los objetivos abstractos al sistema concreto puede ser complejo, la definición de la arquitectura puede ser documentada, diseñada, analizada e implementada de tal manera que las metas del negocio se cumplan.

En específico la arquitectura de software es un set de estructuras necesarias para razonar acerca del sistema, lo que incluye los elementos de software, las relaciones entre ellos, la propiedades que tiene.

La arquitectura es una Abstracción, dado que la arquitectura es una serie de estructuras, elementos y relaciones que intentamos comprender es necesario omitir ciertos detalles, así permitirnos entender cómo cada uno de estos elementos interactúan entre sí .

Patrones de Arquitectura es el Desarrollo de Aplicaciones Móviles

En ingeniería de software, un patrón arquitectónico es una solución general y reutilizable para un problema que ocurre en un contexto particular. Es una solución recurrente a un problema recurrente.

El objetivo del Patrón de arquitectura es comprender cómo se integran las partes principales del sistema y cómo fluyen los mensajes y los datos a través del sistema.

Cuando empiezas a preocuparte un poco más sobre cómo organizar tu código, que patrón de arquitectura usar en tu aplicación y haces una búsqueda de Google te vas a encontrar con muchas posibilidades como MVC, MVP, VIPER, MVI, MVVM, RX, Flux, ReactorKit. Son tan variadas que muchas veces puedes preguntarte cuál es el mejor patrón de arquitectura para poder implementar en mi aplicación .

Cada una tiene sus pros y contras y decir que una es la mejor de todas sería una declaración muy audaz. Lo que sí es cierto es que sea como sea consciente o inconscientemente tu app tendrá un patrón de arquitectura y esto afectará el tiempo en el que logras hacer los cambios, en la velocidad que tendrá tu equipo para resolver bugs, la mantenibilidad del sistema el coverage de Tests aceptable, que tan rápido puedas convertir los requerimientos del negocio en features y que tan productivo es tu equipo.

RxSwift, RxKotlin, ReactorKit, MVI ….

Últimamente me ha dado mucha curiosidad aprender sobre la parte reactive, aprender que patrones de arquitectura se pueden aplicar en el momento que decidimos hacer uso del paradigma de programación funcional reactivo.

He de admitir que no lo he usado en un proyecto real y quiero poder generar mis conclusiones acerca de que tan fácil es aprenderlo, en que momento es un buen momento de usarlo, que dificultades se pueden presentar. Así que estaré escribiendo conforme vaya aprendiendo más sobre la Programación Reactiva en Swift y Kotlin.

Siguiente Post:
Instalación de RxSwift y Paradigmas de programación