Clean Architecture en Android: Una introducción práctica para Indies

Cómo organizar tu código en capas para que tu app crezca sin romperse a pedazos

1. ¿Por qué Clean Architecture y no el Monolito Clásico?

Cuando empezamos a programar en Android, nuestro primer instinto es poner todo el código en el MainActivity.kt o, con suerte, separarlo en un ViewModel gigante de 3000 líneas. A este patrón se le conoce como el "God Object" (el objeto Dios), porque lo hace todo: controla la vista, hace peticiones HTTP, y las guarda en la base de datos.

Como desarrollador Indie que mantiene proyectos como Detedroid y Androfus, te aseguro que el mayor enemigo de tus futuras actualizaciones eres tú mismo. La Clean Architecture busca separar tu código en pequeñas islas (capas) que no saben nada del funcionamiento interno de las demás, haciendo que el proyecto sea infinitamente más testeable y mantenible.

2. Las 3 Capas Fundamentales (MVVM + Clean)

La implementación oficial recomendada por Google suele separar el proyecto fundamentalmente en tres capas, comunicadas entre sí solo en una dirección:

La Capa de Presentación (UI / View)

Aquí habita solo el código relacionado con pintar la pantalla, es decir, el Jetpack Compose, las Actividades, Fragmentos, y los ViewModels. Regla de oro: Esta capa no sabe cómo funciona internet ni cómo es la tabla de la base de datos. Solo sabe decirle al usuario "cargando" y pedirle información al Dominio.

La Capa de Dominio (Domain)

El corazón de tu aplicación. Aquí viven las "reglas de negocio" (Business Logic). No depende de NINGUNA librería de Android, es puro código Kotlin. Posee los modelos de datos que importan para tu lógica y los "Casos de Uso" (UseCases o Interactors). Un caso de uso sería por ejemplo: GenerarDiagnosticoBateriaUseCase. Su única labor es calcular cosas y pedir datos sin importarle quién se los da.

La Capa de Datos (Data layer)

Esta es la capa sucia. Es la encargada de comunicarse con las APIs web (usando Retrofit o Ktor) y con las bases de datos SQLite (usando Room). Proporciona implementaciones de unas "interfaces de repositorio" que han sido definidas previamente en la capa de Dominio.

3. El Flujo de Datos (The Unidirectional Data Flow)

Imaginemos que en la app Detedroid el usuario pulsa un botón para escanear el dispositivo:

  1. La UI (Compose Button) invoca un método en el ViewModel pidiendo iniciar el escaneo.
  2. El ViewModel cambia el estado a "Cargando_UI" y ejecuta una Corrutina que llama a un Caso de Uso en la Capa de Dominio (ej. StartScanUseCase).
  3. El Caso de Uso valida las reglas (ej. "el usuario es premium para hacer este escaneo") y se lo pide a la interfaz IDeviceRepository.
  4. La Capa de Datos, que implementa IDeviceRepositoryImpl, baja la información a nivel de hardware/Android API real, hace sus cálculos brutos, y devuelve un Entity.
  5. El Caso de uso transforma ese Entity sucio en un DomainModel limpio y lo devuelve al ViewModel.
  6. El ViewModel actualiza su StateFlow en vivo y la pantalla se redibuja automáticamente mostrando los resultados.

4. Dependency Inversion ("El Truco Mágico")

La flecha mágica de esta arquitectura dicta una regla inquebrantable de dependencia: Presentacion -> Dominio <- Datos.

Fíjate que tanto Presentación como Datos apuntan hacia el Dominio. ¿Cómo hace el Dominio para pedirle cosas a Datos si no lo conoce? Mediante la Inyección de Dependencias (ej. Dagger Hilt o Koin) y la Inversión de Dependencias. El Dominio dice "Yo exijo que alguien me cumpla esta interfaz/contrato". La capa de Datos implementa esa interfaz en secreto, y la Inyección de Dependencias le pasa el objeto sucio disfrazado con el contrato limpio al Dominio durante la ejecución de la app.

5. Conclusión para el Indie Hacker

Mucha gente dice que Clean Architecture añade "boilerplate" (código inútil y repetitivo). Y en efecto, crear 3 archivos distintos para una simple pantalla de 'Hola Mundo' suena ridículo. ¿El consejo de oro? No lo uses para funciones ridículas.

Úsalo de verdad en el módulo principal y masivo de tu aplicación, donde la complejidad de verdad radica. Verás cómo tus crasheos en producción se desploman, y encontrar bugs pasará de ser doloroso a algo tan trivial como leer qué capa está emitiendo un Flow equivocado.