Android Academy · Aula

Por que modularizar

Velocidade de compilação, responsabilidade e reutilização.

Por que modularizar é uma aula grátis de Android Academy no CoddyKit. Esta é a aula 1 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Android Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Android Academy inclui 4 aulas no total.

O problema do monólito

À medida que um aplicativo Android cresce, todo o seu código costuma ficar em um único módulo app. Isso é um monólito. No início, é conveniente, mas, com o tempo, torna-se difícil de manter: toda alteração afeta o mesmo módulo, as compilações ficam lentas e os membros da equipe constantemente atrapalham o trabalho uns dos outros.

Modularização significa dividir esse grande módulo em vários módulos Gradle menores e focados. Nesta lição, você aprenderá por que as equipes fazem isso e quais benefícios concretos essa prática proporciona.

O que é realmente um módulo

No Gradle, um módulo é uma unidade de código que pode ser compilada de forma independente e possui seu próprio arquivo build.gradle.kts. Seu aplicativo já tem pelo menos um: o módulo :app. Você declara cada módulo em settings.gradle.kts.

Adicionar um módulo é tão simples quanto incluí-lo. Cada módulo produz sua própria saída de compilação e pode depender de outros módulos.

// settings.gradle.kts
include(":app")
include(":core:designsystem")
include(":core:data")
include(":feature:home")
include(":feature:profile")

Benefício 1: compilações mais rápidas

O maior ganho prático é a velocidade de compilação. O Gradle pode compilar módulos em paralelo e, principalmente, armazenar em cache e ignorar módulos cujas entradas não foram alteradas.

Se você editar apenas :feature:profile, o Gradle reutilizará as saídas já compiladas de todos os outros módulos. Em um monólito, qualquer alteração pode forçar a recompilação do aplicativo inteiro.

Execução paralela entre módulos
Compilações incrementais: recompilar apenas o que mudou
Melhores taxas de acerto do cache remoto/de compilação

// gradle.properties
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configuration-cache=true

Benefício 2: limites claros

Os módulos impõem limites. O código de um módulo só pode acessar o que outro módulo expõe deliberadamente. Isso evita a confusão de código emaranhado em que cada classe acessa todas as outras classes.

Você controla a visibilidade com as configurações Gradle api e implementation. implementation mantém uma dependência privada ao módulo; os consumidores não podem usá-la acidentalmente.

// feature/profile/build.gradle.kts
dependencies {
    // Exposed to whoever depends on :feature:profile
    api(project(":core:model"))

    // Private: hidden from consumers of this module
    implementation(project(":core:network"))
}

Benefício 3: reutilização

Quando a lógica vive em um módulo focado, você pode reutilizá-la em qualquer lugar. Um módulo :core:designsystem que contenha seu tema, suas cores e seus componentes reutilizáveis pode ser compartilhado por todas as funcionalidades.

A mesma ideia se aplica a vários aplicativos: uma empresa pode compartilhar um módulo :core:network entre vários produtos, em vez de copiar o código.

// Any feature can pull in shared building blocks
// feature/home/build.gradle.kts
dependencies {
    implementation(project(":core:designsystem"))
    implementation(project(":core:data"))
}

Benefício 4: responsabilidade da equipe

Os módulos correspondem naturalmente à responsabilidade das equipes. A equipe de pagamentos é responsável por :feature:payments; a equipe de perfil é responsável por :feature:profile. Elas podem trabalhar em paralelo com menos conflitos de mesclagem, pois o código fica em pastas e arquivos de compilação separados.

Ferramentas como um arquivo CODEOWNERS podem solicitar automaticamente revisões à equipe correta com base no caminho do módulo.

# .github/CODEOWNERS
/feature/payments/   @org/payments-team
/feature/profile/    @org/profile-team
/core/designsystem/  @org/platform-team

Benefício 5: encapsulamento por visibilidade

Dentro de um módulo, o modificador internal do Kotlin se torna muito poderoso. Uma classe ou função internal fica visível somente dentro do próprio módulo. Outros módulos literalmente não podem referenciá-la.

Isso permite expor uma pequena superfície pública e ocultar os detalhes de implementação, algo impossível de impor em um único módulo gigantesco.

// In :core:data
// Public API other modules may use
fun interface UserRepository {
    suspend fun loadUser(id: String): User
}

// Hidden from other modules
internal class DefaultUserRepository(
    private val api: UserApi
) : UserRepository {
    override suspend fun loadUser(id: String) = api.fetch(id).toUser()
}

O custo: alguma sobrecarga

A modularização não é gratuita. Cada módulo acrescenta um build.gradle.kts para manter, e você precisa decidir qual módulo é responsável por cada parte do código. Modularizar demais um aplicativo pequeno gera trabalho sem trazer benefícios.

Uma regra prática: modularize quando os tempos de compilação forem um problema, quando as equipes entrarem em conflito ou quando você tiver camadas reutilizáveis claras. Um aplicativo de hobby feito em um fim de semana raramente precisa de 30 módulos.

Uma estrutura típica de módulos

Uma estrutura comum e escalável divide os módulos nas camadas app, feature e core. O módulo :app conecta tudo; as funcionalidades contêm as telas voltadas ao usuário; os módulos principais contêm a infraestrutura compartilhada.

// Conceptual project tree
// app/                  <- single entry point, wires features
// feature/
//   home/
//   profile/
//   settings/
// core/
//   designsystem/       <- theme + reusable composables
//   data/               <- repositories
//   network/            <- Retrofit/Ktor
//   model/              <- shared data classes

Plugins de convenção mantêm tudo organizado

Com muitos módulos, copiar e colar a mesma configuração do Gradle em todos os lugares é uma armadilha. As equipes extraem a configuração compartilhada para plugins de convenção (em um módulo build-logic). Assim, cada módulo real aplica um único plugin, em vez de repetir dezenas de linhas.

Você verá esse padrão em aplicativos grandes de código aberto, como o Now in Android. Por enquanto, basta conhecer o objetivo: manter os arquivos de compilação pequenos e consistentes.

// feature/home/build.gradle.kts
plugins {
    // One convention plugin sets up Android + Compose + Kotlin
    id("myapp.android.feature")
}

android { namespace = "com.myapp.feature.home" }

Mentalidade: pense em camadas

O modelo mental mais útil é este: as dependências devem fluir para baixo. As funcionalidades dependem do core; o core não depende das funcionalidades. O módulo :app fica no topo e depende de tudo aquilo de que precisa para montar o aplicativo.

Se você mantiver essa direção consistente, o grafo de módulos permanecerá organizado e você evitará ciclos, que serão explorados em uma lição posterior.

// Allowed:  app -> feature -> core
// Forbidden: core -> feature (upward) or feature -> feature (sideways)
// app/build.gradle.kts
dependencies {
    implementation(project(":feature:home"))
    implementation(project(":feature:profile"))
}

Verificação rápida

Qual das opções a seguir é o benefício mais concreto e cotidiano que as equipes obtêm ao modularizar um aplicativo Android em crescimento?

Recapitulação: por que modularizar

Você aprendeu por que as equipes dividem um monólito em módulos:

Compilações mais rápidas por meio da execução paralela e do armazenamento incremental em cache
Limites claros usando api/implementation e internal
Reutilização de camadas principais, como o sistema de design e a rede
Responsabilidade da equipe com menos conflitos de mesclagem

Você também viu o custo (arquivos de compilação adicionais) e a regra de ouro: as dependências fluem para baixo, app -> feature -> core. Em seguida, você definirá os limites reais entre os módulos de funcionalidades e principais.

Perguntas Frequentes

A aula “Por que modularizar” é grátis?

Sim — o texto completo de “Por que modularizar” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Android Academy, atualize para CoddyKit PRO. O curso de Android Academy inclui 4 aulas no total.

O que vou aprender em “Por que modularizar”?

Velocidade de compilação, responsabilidade e reutilização. Você pratica Android Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Android Academy?

Nenhuma experiência prévia é necessária. Android Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 1 de 4.

Quanto tempo leva a aula “Por que modularizar”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Android Academy?

Sim. Cada aula de Android Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

← Voltar para Android Academy