Criando seu primeiro app modular: como quebrar um monolito em poucos dias · adonaipinheiro

Sexta-feira, 14h. Você abre o projeto que herdou e percebe que o MainActivity tem 3 000 linhas, a pasta lib/ parece uma bagunça de 200 arquivos e cada mudança pequena vira uma guerra de merge. Se isso soa familiar, bem-vindo ao clube. A boa notícia é que modularizar um app não precisa de reescrita total: dá para começar hoje e entregar valor já na próxima sprint.

Por que modularizar importa agora

Mesmo sem grandes anúncios de novas ferramentas, a modularização é a única técnica que continua sendo discutida em toda talk de arquitetura — simplesmente porque escala. Equipes maiores, builds mais rápidos, testes isolados e menos conflitos de merge são ganhos imediatos. O pulo do gato é fazer isso sem parar as entregas.

O plano de 4 passos para não quebrar nada

1. Escolha o primeiro módulo com frieza

Liste tudo o que seu app faz em 3 minutos. Saúde, login, pagamento, perfil… Agora responda: qual desses nunca muda junto com o resto? Geralmente é o core de autenticação ou serviço de analytics. Esse será seu módulo piloto.

Exemplo prático no Android (Gradle Kotlin DSL):

// settings.gradle.kts
include(":app", ":core:auth")

// core/auth/build.gradle.kts
plugins { id("com.android.library") }
android { namespace = "com.seuapp.core.auth" }
dependencies {
    implementation("androidx.security:security-crypto:1.1.0-alpha06")
}

2. Mova o mínimo possível

Nada de arrancar tudo de uma vez. Copie apenas as 3 classes essenciais para o novo módulo (ex: AuthRepository, TokenManager, LoginUseCase). Faça o app compilar antes de ir para a próxima. Isso costuma levar menos de 30 minutos.

Dica: use o Android Studio Refactor > Move para que as importações sejam corrigidas automaticamente. No Xcode, o Refactor > Move to Group já cria o target certo.

3. Torne a dependência reversível

Crie um wrapper no módulo original que delega pro novo. Assim, qualquer bug pode ser desfeito com um git revert simples.

// Dentro do app
class LegacyAuth(private val real: NewAuth) {
    fun login(user: String, pass: String) = real.login(user, pass)
}

Isso mantém a interface antiga intacta e o time continua enviando PRs sem aprender nada novo.

4. Entregue valor em produção

Empurre o módulo para a loja mesmo que ele só tenha 3 classes. O importante é validar a estrutura de build, CI/CD e crash-reporting. Com o primeiro módulo rodando, o resto fica psicologicamente mais fácil.

O que evitar (para não pagar divida técnica)

Não crie um módulo "common" no início. Vira um saco de gatos em dois dias. Espere até ter pelo menos 3 módulos que realmente precisem compartilhar algo.
Evite dependências circulares. Se auth precisa de profile e profile precisa de auth, o problema é de design, não de pasta. Use interfaces ou um terceiro módulo core:models.
Não confunda módulo com camada. Ter data, domain, presentation não é modularização — é separação de responsabilidade. Módulos devem representar funcionalidades, não camadas.

Checklist para a primeira sexta-feira

Tempo estimado: 2 horas
Branch separada para testes
CI configurado para rodar testes do novo módulo
Documentação de um parágrafo explicando o que o módulo faz

Depois de entregar, meça: build ficou mais rápido? Quantos conflitos de merge sumiram? Esses números vão convencer o restante do time mais que qualquer slide.

Na próxima semana, escolha outro pedaço e repita. Em um mês você terá 4 módulos pequenos e um time que já esqueceu o drama do monolito.