

Este projeto é uma implementação frouxa da arquitetura limpa, conforme apresentado em meu livro, Clean Architecture for Android. É um projeto nativo do Android escrito em Kotlin. Ele demonstra os principais princípios apresentados no livro e como eles se aplicam a um projeto da vida real.
Vou me esforçar para manter este projeto atualizado e usá -lo para demonstrar os pontos fortes da arquitetura: escalabilidade , testabilidade e flexibilidade quando se trata de escolher soluções de terceiros.
Simplicidade
" A complexidade introduzida aqui é um exagero! "
Concordo. Se este fosse um projeto final , ao qual nenhuma nova funcionalidade seria adicionada, a arquitetura limpa teria sido excessivamente complicada para isso. No entanto, a realidade é que o projeto móvel raramente é final. Feedback do usuário, requisitos de marketing, novas tecnologias - esses fatores e outros levam a mudanças contínuas em quase todos os projetos. E assim, o que agora pode parecer muita complexidade nos recompensará quando chegar a hora da mudança. Isso será quando a arquitetura limpa brilhar.
Como nota lateral: de certa forma, eu compliquei demais esse projeto, introduzindo diferentes tecnologias. O objetivo era mostrar como, mesmo em cenários da vida real, onde um projeto pode ter crescido ao longo do tempo para incluir mais de uma solução tecnológica, a arquitetura ainda funciona.
Mapeadores como aulas versus funções de extensão de mapeamento
Ao mapear entre os modelos, temos várias opções. A decisão principal é entre classes de mapeador e funções de extensão de mapeamento.
Embora as funções de extensão sejam mais concisas, usá -las para mapear os limites de nossas opções de estruturas de teste (Mockito, por exemplo, não pode extrair funções estáticas).
Que tal injetar as funções de extensão do mapeador? Nós poderíamos fazer isso. No entanto, isso remove os benefícios da concisão quase inteiramente. Também dificulta a navegação para a implementação.
E assim, optei pelas classes de mapeador de concreto ligeiramente mais detalhadas.
Pulando componentes de arquitetura do Google
O maior problema dos componentes da arquitetura do Google é que eles vazam detalhes do Android na camada de apresentação. Isso impede que a camada de apresentação seja verdadeiramente agnóstica da interface do usuário.
Outra questão com os componentes da arquitetura é que eles dão muita responsabilidade ao ViewModel. Eles tornam o estado persistente que não possui, levando a possíveis bugs de sincronização de dados.
Por esses motivos, enquanto ainda segue a MVVM, este projeto depende de fluxos de Kotlin em vez de Livivedata , e implementa os models de vista pura em vez de o Google.
Estrutura de zombaria
Tanto o Mockito-Kotlin quanto o Mockk são usados neste projeto para demonstrar como o uso de cada um seria.
Minha preferência pessoal permanece Mockito-Kotlin . Acho o código mais fácil de ler e seguir ao usá -lo. No momento da redação deste artigo, a julgar pelo número de estrelas em cada repositório, a indústria parece se inclinar para Mockk.
Foi -me perguntado sobre o uso de falsificações . Eu explorei falsificações e achei que eram excessivamente detalhadas e muito caras para manter.
Estrutura de injeção de dependência
Uma parte crítica da maioria dos aplicativos modernos, a injeção de dependência (DI) nos ajuda a obter os objetos que criam nosso aplicativo. Também ajuda a gerenciar seu escopo. As escolhas mais populares no mundo do Android são o punho (que é construído em cima de Dagger) e Koin.
Hilt foi escolhido por dois motivos principais:
Xml vs jetpack compõe
Por que não ambos? Ainda tenho muitas preocupações em torno da composição do JetPack . Mesmo assim, era importante para mim mostrar que a arquitetura apresentada funciona bem, independentemente do mecanismo da interface do usuário escolhido. Como exercício, convido você a tentar substituir a camada da interface do usuário da composição ao XML ou vice -versa sem atualizar a camada de apresentação.
Arquitetura limpa para Android na Amazon
Arquitetura limpa no blog de codificador limpo
As contribuições para este projeto são bem -vindas. Sinta -se à vontade para relatar quaisquer problemas ou garfo para fazer alterações e aumentar uma solicitação de tração.
Este projeto é distribuído sob os termos da licença do MIT. Consulte License.md para obter detalhes.