Projetos Android que começam simples frequentemente evoluem para um emaranhado onde a lógica de negócio está misturada com código de UI e acesso a banco de dados no mesmo Activity ou Fragment. Quando isso acontece, adicionar uma nova funcionalidade se torna arriscado, e escrever testes automatizados praticamente impossível sem simular toda a plataforma Android. Clean Architecture resolve esse problema organizando o código em camadas com responsabilidades e dependências bem definidas. Neste artigo, explicamos como aplicar esses princípios em projetos Android reais.
O princípio central: dependências apontam para dentro
Na Clean Architecture, o código é organizado em camadas concêntricas, onde as camadas externas (UI, banco de dados, APIs) podem depender das camadas internas (regras de negócio), mas nunca o contrário. Isso significa que a lógica de negócio central do aplicativo não sabe nada sobre Android, Room, Retrofit ou qualquer framework específico — ela é Kotlin puro, testável isoladamente, e sobrevive a mudanças de framework ou biblioteca sem precisar ser reescrita.
As três camadas principais
Domain (domínio): contém as regras de negócio puras — entidades, casos de uso (use cases) e interfaces de repositório, sem nenhuma dependência de Android ou de bibliotecas externas.
Data (dados): implementa as interfaces definidas no domínio, lidando com a origem real dos dados — seja banco de dados local (Room), API remota (Retrofit) ou uma combinação de ambos com lógica de cache.
Presentation (apresentação): contém ViewModels e a UI propriamente dita (Composables ou Views tradicionais), consumindo os casos de uso da camada de domínio sem conhecer os detalhes de como os dados são obtidos.
// Camada de domínio — não conhece Android nem Retrofit
class ObterPedidosUseCase(private val repository: PedidoRepository) {
suspend operator fun invoke(usuarioId: String): List {
return repository.buscarPedidos(usuarioId)
}
} Se o código da sua regra de negócio não compila fora de um projeto Android, ele provavelmente está acoplado demais à plataforma — e isso vai custar caro na primeira vez que uma dependência precisar mudar.
Testabilidade como consequência direta, não como esforço extra
Uma das maiores vantagens práticas da Clean Architecture é a testabilidade natural que ela proporciona. Como a camada de domínio não depende do Android SDK, é possível escrever testes unitários que rodam em milissegundos, sem precisar de um emulador ou dispositivo físico. Isso muda completamente a dinâmica de desenvolvimento: testes deixam de ser algo custoso e demorado para se tornarem parte natural do ciclo de desenvolvimento diário.
Injeção de dependência: Hilt como padrão recomendado
Para que as camadas se comuniquem sem acoplamento direto, é necessário um mecanismo de injeção de dependência. Hilt, construído sobre o Dagger e oficialmente recomendado pelo Google, automatiza grande parte da configuração necessária, permitindo que ViewModels recebam casos de uso, e casos de uso recebam repositórios, sem que cada camada precise saber como instanciar suas próprias dependências.
Quando vale (e quando não vale) aplicar Clean Architecture completa
Para aplicativos pequenos, com poucas telas e regras de negócio simples, aplicar Clean Architecture em sua forma mais rigorosa pode adicionar complexidade desproporcional ao benefício real. A recomendação prática é adotar os princípios centrais — separação clara entre lógica de negócio e detalhes de framework — de forma proporcional ao tamanho e à expectativa de crescimento do projeto, sem necessariamente implementar todas as camadas e abstrações da forma mais purista possível desde o primeiro commit.
Considerações finais
Clean Architecture não é sobre seguir um diagrama à risca, mas sobre um princípio fundamental: isolar as regras de negócio do aplicativo de detalhes de implementação que podem mudar — banco de dados, biblioteca de rede, ou até o próprio framework de UI. Aplicado com bom senso, esse princípio resulta em projetos mais testáveis, mais fáceis de manter e mais resistentes a mudanças ao longo do tempo. Se sua empresa está desenvolvendo um aplicativo Android e quer garantir uma base arquitetural sólida, a equipe da ASL Software Engineering pode ajudar. Fale com a gente.
