Arquitectura de aplicaciones: fundamentos de errores comunes

Una aplicación puede ser hermosa por fuera, pero si la arquitectura interna es mala, será lenta, difícil de mantener y llena de errores. Arquitectura de software define cómo se organizan y se comunican las partes del código entre sí. Es la base del edificio.

Si está iniciando o ha heredado un proyecto heredado, comprenda los fundamentos para no construir un castillo de naipes.

¿Qué es la buena arquitectura?

Una buena arquitectura debería ser:

Escalable: Fácil de agregar nuevas funciones sin romper las antiguas.
Comprobable: Fácil de escribir pruebas automatizadas.
Mantenible: cualquier desarrollador nuevo debe comprender el código rápidamente.

Normas comunes (sopa de letras)

MVC (Modelo-Vista-Controlador)

El clásico.

Modelo: Datos.
Ver: Pantalla.
Controlador: Lógica que conecta los dos.
Problema: En aplicaciones móviles, el Controlador tiende a volverse gigantesco (Massive View Controller), concentrando demasiada responsabilidad.

MVVM (Modelo-Ver-VerModelo)

El estándar moderno de la industria (Android Jetpack, iOS Swift UI).

ViewModel: prepara datos específicamente para que se muestren en la Vista. La Vista "observa" el Modelo de Vista. Si los datos cambian, la pantalla se actualiza sola (Reactividad).
Ventaja: Separa muy bien la lógica de la interfaz.

Arquitectura limpia

Propuesto por Robert C. Martin (tío Bob). Divide la aplicación en capas (cebolla).

Core (Dominio): Reglas comerciales puras (no saben que es una aplicación).
Datos: Repositorios, API, Base de datos.
Presentación: UI, ViewModels. La regla es: Las capas de afuera conocen las capas de adentro, pero las capas de adentro NO conocen las capas de afuera. El Core no sabe si se está ejecutando en un iPhone o en un microondas.

Errores fundamentales

Lógica en la interfaz de usuario: coloque reglas comerciales ("si el saldo <0, coloréelo de rojo") directamente en el archivo de pantalla. Esto hace que sea imposible realizar pruebas sin ejecutar el emulador.
Acoplamiento fuerte: si cambia la biblioteca API (Retrofit) y tiene que reescribir las pantallas, su acoplamiento es incorrecto. Utilice la inyección de dependencia.
Objetos de Dios: Clases que hacen de todo (llamar API, guardar en la base de datos, formatear datos). Dividir en clases pequeñas con una sola responsabilidad (SÓLIDO).

Conclusión

No existe una “arquitectura perfecta”, existe la arquitectura adecuada al tamaño del proyecto. Para un MVP, un MVC simple servirá. Para una Super App, la Arquitectura Limpia es obligatoria. Lo importante es elegir un estándar y seguirlo consistentemente.