He liderado la migración a Clean Architecture + MVVM de aplicaciones de banca digital, definiendo el estándar de arquitectura y revisión de código que después adoptaron otros squads del mismo cliente. No fue un ejercicio académico: eran apps en producción, con usuarios activos y requisitos estrictos de seguridad y disponibilidad, en una organización de más de 200 desarrolladores repartidos en varios equipos. Esto es lo que aprendí del proceso.

Por qué migrar

Las apps legacy con las que empezamos tenían un problema común: la lógica de negocio estaba mezclada con la capa de presentación y con detalles de infraestructura (llamadas de red, persistencia). El resultado práctico era testing unitario difícil de escribir, onboarding lento para desarrolladores nuevos en el proyecto, y fricción cada vez que dos squads tocaban el mismo módulo sin un criterio compartido de dónde debía vivir cada responsabilidad.

El estándar que definimos

Separamos el código en tres capas con una regla de dependencia clara: data (fuentes de datos, red, persistencia), domain (casos de uso y modelos de negocio, sin dependencias de framework) y presentation (MVVM, ViewModels y estado de UI con Compose). La regla no negociable: las capas internas no conocen a las externas. El domain no sabe que existe Retrofit o Room; solo conoce interfaces que la capa de datos implementa.

Documentar la regla no bastaba: había que hacerla visible y verificable en el día a día. Por eso el estándar se apoyó en revisión de código sistemática y en herramientas de análisis estático (SonarQube) que detectaban violaciones de capas antes de que llegaran a producción.

Coordinar varios squads sin frenar entregas

La migración fue incremental por necesidad: no se puede parar el desarrollo de una app bancaria en producción para reescribirla. Migramos módulo a módulo, conviviendo temporalmente con código legado, priorizando las áreas con más cambios frecuentes o más incidencias. El punto crítico fue actuar como referente técnico entre squads: mismas convenciones, mismos criterios de revisión, para que el código de un equipo no chocara con las decisiones de otro cuando ambos tocaban capas compartidas.

Resultados

  • Base de código más mantenible y consistente entre equipos, con menos fricción al incorporar funcionalidades críticas.
  • Testing unitario real del domain, sin necesidad de mocks pesados de framework.
  • Onboarding más rápido: un desarrollador nuevo entiende antes dónde debe vivir cada cambio.

Errores que evitaría la próxima vez

El riesgo principal de Clean Architecture a escala no es no aplicarla, es aplicarla de forma dogmática: crear capas e interfaces para casos que no las necesitan, o forzar el mismo patrón en un módulo pequeño que ninguna otra parte del sistema va a reutilizar. La arquitectura tiene que resolver un problema real de mantenibilidad, no ser un fin en sí misma. En proyectos con presión de negocio y varios squads, mantener ese equilibrio —consistencia sin sobreingeniería— es más parte del trabajo que escribir el código en sí.

Un estándar de arquitectura solo funciona si es más fácil de seguir que de saltarse.