< Insights

Clean Architecture com MVVM: o que é, vantagens e como utilizar em aplicações Android

  • Desenvolvimento de Software

Com o decorrer dos anos, aplicações complexas em Android são criadas, utilizando diversas arquiteturas existentes como: Model-View-Controller, Model-View-Presenter, Model-View-ViewModel, entre outros. O surgimento da Clean Architecture por um dos maiores influenciadores na comunidade global de desenvolvimento, Robert C. Martin, também conhecido como Uncle Bob, autor de um livro abordando este tema, contribuiu para a criação de uma arquitetura em que os componentes fossem desacoplados, testáveis e de fácil manutenção.

O que é a Clean Architecture?

A Clean Architecture consiste em um diagrama de camadas, em que cada um dos seus componentes possuem suas próprias responsabilidades e cada uma delas tem conhecimento apenas de camadas de dentro, ou seja, a camada de “Frameworks e Drivers” enxerga somente a de “Interface Adapters” e assim sucessivamente. 

Vantagens de utilizar a Clean Architecture

  • O código é facilmente testável, se comparado a arquitetura MVVM simples;
  • Componentes ainda mais desacoplados, a estrutura do pacote é facilmente de se navegar entre eles; 
  • Novas funcionalidades podem ser adicionadas rapidamente pelo time de desenvolvedores.

  Desvantagens de utilizar a Clean Architecture

  • Curva de aprendizado relativamente íngreme, considerando que todas as camadas funcionam juntas, exigindo um certo tempo para entender seus conceitos, principalmente desenvolvedores provenientes de padrões como MVVM e MVP simples;
  • Pela arquitetura exigir o acréscimo de muitas classes adicionais, este modelo não é ideal para projetos de baixa complexidade.

A intenção é de demonstrar as regras de dependência dentro da arquitetura.

imagem demonstrando as regras de dependência dentro da clean architecture

Entidades (Entities)

O conceito principal é de que esta camada deve conter tudo que seja pertinente ao sistema em relação a lógica de negócios, de modo mais genérico possível, ou seja, que tenham menor probabilidade de alterações quando houverem mudanças externas. Nesta camada se encontram os modelos de objetos utilizados para a lógica de negócios, como os POJOs (Plain Old Java Object) e Data Class em Kotlin.

Casos de Uso (Use Cases)

Se encontram nesta camada, as regras de negócios mais específicas do sistema e ainda, é o lugar onde será verificado como a camada de apresentação receberá os dados. 

Adaptadores de Interface (Interface Adapters)

Esta camada tem como responsabilidade, realizar a conversão dos dados, de modo que seja mais acessível e conveniente possível, para as camadas de Entidades e Casos de Uso.

Como exemplo, são capturados dados de entrada em uma interface de usuário e os empacotam de modo conveniente para os casos de uso e entidades. Logo em seguida, recupera os dados de saída dos casos de uso e entidades, e as empacotam em um formato conveniente para que sejam exibidos na interface de usuário ou sejam salvos em um banco de dados.

Frameworks

A camada mais externa geralmente é composta de estruturas e ferramentas de  banco de dados, web, interface de usuário, etc. Nesta camada, deve possuir o mínimo de código possível e necessário de modo a interligar as camadas e interferir o mínimo possível.

As camadas de MVVM com Clean Architecture no Android

Utilizando esta arquitetura em aplicações Android, que é a combinação da arquitetura MVVM e Clean Architecture, os códigos se dividem em três camadas distintas:

Camada de Apresentação (Presentation Layer):

Nesta camada, são incluídas as “Activity”s, “Fragment”s como sendo as “Views”, e as “ViewModel”s, devem ser mais simples e intuitivo possível e ainda, não devem ser incluídas regras de negócio nas “Activity”s e “Fragment”s.

Uma “View” irá se comunicar com sua respectiva “ViewModel”, e assim, a “ViewModel” se comunicará com a camada de domínio para que sejam executadas determinadas ações. Uma “ViewModel” nunca se comunicará diretamente com a camada de dados;

Camada de Domínio (Domain Layer):

Na camada de domínio, devem conter todos os casos de uso da aplicação. Os casos de uso tem como objetivo serem mediadores entre suas “ViewModel”s e os “Repository”s.

Caso for necessário adicionar uma nova funcionalidade, tudo o que deve ser feito é adicionar um novo caso de uso e todo seu respectivo código estará completamente separado e desacoplado dos outros casos de uso. A criação de um novo caso de uso é justamente para evitar que ao adicionar novas funcionalidades, quebrar as preexistentes no código;

Camada de Dados (Data Layer):

Esta camada possui todos os repositórios que a camada de domínio tem disponíveis para utilização e “DataSource”s, que são responsáveis por decidir qual a fonte em que devem ser recuperados os dados, sendo de uma base de dados local ou servidor remoto.

repositórios que a camada de domínio tem disponíveis para utilização e “DataSource”s

O fluxo de comunicação entre as camadas, pode ser ilustrado conforme o diagrama a seguir:

fluxo de comunicação entre as camadas da clean architecture

O propósito não é mostrar qual arquitetura é ideal para todas as aplicações, mas apresentar uma arquitetura que seja de maior escalabilidade, testável e tenha facilidade em manutenção para projetos de maior complexidade. 

Embora seja uma arquitetura com grau alto de aprendizado na implantação, se torna uma solução de grande viabilidade a longo prazo, para realizar sua manutenção e testes, a Clean Architecture de acordo com minha experiência com desenvolvimento mobile, é uma solução com grande viabilidade em projetos de maior complexidade.

Sugira um artigo

    Para enviar o formulário é necessário o aceite das políticas.

    Insights do nosso time

    Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.