Una buena arquitectura también se siente al usar una app

Una aplicación puede parecer sencilla por fuera y acumular muchas decisiones por dentro. Qué ocurre si una petición falla, cómo se conserva una búsqueda o de dónde viene un dato son decisiones que terminan formando parte de la experiencia.

Empezar por el comportamiento

Antes de decidir carpetas, describo los estados que una pantalla debe comunicar. Una lista de rutas, por ejemplo, necesita distinguir entre estar cargando, no tener resultados, mostrar contenido y no poder actualizarse.

Si estas situaciones quedan implícitas en una combinación de booleanos, es fácil construir estados imposibles. Una representación explícita ayuda a que el comportamiento sea más fácil de revisar.

sealed interface RoutesState {
    data object Loading : RoutesState
    data object Empty : RoutesState
    data class Content(val routes: List<Route>) : RoutesState
    data class Error(val message: String) : RoutesState
}

El ejemplo es deliberadamente pequeño. En una aplicación real, también distinguiría la carga inicial de una actualización con contenido visible para evitar que la pantalla desaparezca al refrescar.

Separar lo que cambia por motivos distintos

La presentación interpreta el estado. Un caso de uso coordina una intención. Un repositorio ofrece acceso a información sin obligar a la pantalla a conocer HTTP o una base de datos.

Esta separación es útil cuando existe una responsabilidad clara. Crear una interfaz para cada clase, aunque no aporte un límite real, puede hacer que una funcionalidad pequeña sea más difícil de seguir.

Una prueba que sí cuenta

Una comprobación valiosa sería: «si falla la actualización, las rutas que ya estaban guardadas siguen disponibles». Esta prueba describe una promesa al usuario y puede sobrevivir a cambios de implementación.

La arquitectura merece su espacio cuando ayuda a mantener una promesa del producto.

Dejar espacio para aprender

No hace falta prever cada posible evolución. Empieza con límites sencillos, observa qué partes cambian juntas y refactoriza cuando haya evidencia. El objetivo es que la siguiente decisión sea más fácil, no conseguir un diagrama más grande.