El argumento real a favor de modularizar

La justificación más repetida — "es una buena práctica" — no ayuda a tomar la decisión. El argumento concreto es este: en un proyecto con un solo módulo, cualquier cambio en cualquier archivo puede invalidar la caché de compilación de todo el proyecto. Con módulos separados, Gradle solo recompila los módulos que cambiaron y sus dependientes directos.

En proyectos grandes, la diferencia entre un build incremental de 8 minutos y uno de 45 segundos es, en la mayoría de los casos, modularización.

Pero el tiempo de build es solo uno de los beneficios. El más importante a largo plazo es otro:

Los beneficios concretos

• Build incremental real: Gradle recompila solo lo que cambió. Un cambio en :feature:checkout no recompila :feature:productos ni :core:network.
• Límites de visibilidad forzados por el compilador: si :feature:checkout no depende de :feature:productos, es imposible que un dev llame accidentalmente a código de otra feature. El compilador lo prohíbe.
• Ownership claro: en equipos de varios devs, cada módulo tiene un responsable. Los conflictos de merge se reducen porque los equipos trabajan en módulos distintos.
• Testabilidad mejorada: un módulo con bordes bien definidos es mucho más fácil de testear de forma aislada que código entremezclado.
• Reutilización real: un módulo :core:ui bien definido puede usarse en múltiples apps del mismo equipo sin copiar código.
• Dynamic Feature Modules: solo posible con App Bundle + módulos separados. Permite descargar partes de la app a demanda.

Los costos reales — los que nadie menciona

La mayoría de los artículos sobre modularización no mencionan los costos. Son reales y no son menores:

• Complejidad de configuración inicial: cada módulo tiene su propio build.gradle. Sin convention plugins (lección 06), el mantenimiento se vuelve tedioso rápidamente.
• Fricción para features simples: agregar una feature nueva requiere crear el módulo, configurar Gradle, configurar Hilt, y conectar la navegación. En un monolito, es agregar una clase.
• Errores de compilación más crípticos: los errores de dependencias circulares o de visibilidad entre módulos son difíciles de leer para alguien que no conoce bien Gradle.
• El primer módulo es el más costoso: la infraestructura necesaria (convention plugins, módulo de testing, configuración de navigation) tiene un costo fijo que hay que pagar independientemente de cuántos módulos tengas.

Cuándo sí modularizar

• El equipo tiene más de 3-4 devs trabajando en paralelo en features distintas.
• Los builds limpios tardan más de 3-4 minutos y ya optimizaste Gradle (daemon, caché, parallel builds).
• Necesitás Dynamic Feature Modules para la distribución.
• El mismo código base va a servir a múltiples apps (white-label, apps de empresa con variantes).
• Tenés features con ciclos de vida muy distintos — algunas cambian todos los días, otras no se tocan hace meses.

Cuándo NO modularizar

• El proyecto tiene menos de 50-60 pantallas y un equipo de 1-3 personas. La organización en paquetes por feature es suficiente y mucho más simple.
• La app está en fase de prototipo o exploración. Modularizar código que va a cambiar radicalmente la semana que viene es desperdiciar tiempo.
• No tenés convention plugins listos. Sin ellos, la deuda de mantenimiento de los build.gradle supera rápidamente el beneficio del build incremental.

La regla concreta

Antes de modularizar, tenés que poder responder sí a estas tres preguntas:

# Pregunta 1: ¿Tenés convention plugins listos?
# Sin esto, cada módulo nuevo es mantenimiento manual. No modularices sin ellos.

# Pregunta 2: ¿Podés definir claramente el contrato de cada módulo?
# "Este módulo expone X y necesita Y" — si no podés escribirlo en dos líneas,
# el módulo no está listo para ser independiente.

# Pregunta 3: ¿El beneficio justifica la fricción para este proyecto HOY?
# No en seis meses cuando "crezca". Hoy.

# Si las tres respuestas son sí → modularizá.
# Si alguna es no → primero resolvé eso.