Por qué modularizar

Gradle te deja dividir el build en piezas. Eso permite aislar features, compartir código, mejorar navegación mental y reducir impacto de cambios. Pero modularizar no es gratis: suma complejidad y reglas.

Tipos de módulo

  • :app como punto de entrada.
  • Módulos de librería Android para UI o features.
  • Módulos Kotlin puros para dominio, utilidades o modelos.
  • Módulos core compartidos.
include(":app")
include(":core:ui")
include(":core:network")
include(":feature:checkout")
include(":feature:profile")

No hay una única estructura válida, pero sí una regla fuerte: cada módulo debería existir por una razón clara, no por moda.

Reglas de dependencia

Lo más sano es que las dependencias formen un grafo entendible. Si cualquier módulo puede depender de cualquier otro, Gradle deja de ayudarte a ordenar el proyecto.

Punto claveUna buena modularización no se evalúa por la cantidad de módulos sino por la claridad de sus fronteras.

  • Evitá dependencias circulares.
  • Preferí contracts estables.
  • No pongas librerías pesadas en módulos que todos consumen si no hace falta.
  • Separá dominio puro de Android cuando tenga sentido.

Cómo migrar sin romper todo

La forma razonable de modularizar una app existente es empezar por extraer algo estable: un módulo de diseño, uno de modelos compartidos o una feature encapsulada.

AtenciónUn error frecuente es crear diez módulos en una semana sin una política de ownership ni reglas de dependencia. Eso produce más fricción que mejora.

Cierre

Gradle es la herramienta que hace posible modularizar, pero la arquitectura sigue siendo la que manda. En la próxima lección usamos ese poder para resolver otra necesidad frecuente: generar múltiples variantes de una misma app.