A importância da Clean Architecture no Flutter
- Desenvolvimento de Software
Hoje vamos falar mais sobre o Flutter, uma ferramenta que surgiu com o mesmo propósito que o React Native: desenvolver aplicativos híbridos com uma base de código.
O que é o Flutter?
O Flutter é uma ferramenta desenvolvida pelo Google, gratuito e de código aberto, para criação de aplicativos nativos, compilados para dispositivos móveis Android e iOS, Web e Desktop, utilizando um único código fonte base em linguagem Dart.
Vantagens de utilizar o Flutter?
- Maior velocidade e dinamismo no desenvolvimento de Apps Mobile;
- Único código fonte para múltiplas plataformas;
- Aplicativos funcionam mais rápido e suave;
- Design dos aplicativos com alta fidelidade visual;
- Semelhança de UIs (User Interface) em dispositivos mais antigos;
- Perfeito para construir MVPs (Minimum Viable Product).
Desvantagens de utilizar o Flutter?
- Não há tanto suporte de bibliotecas, como em desenvolvimento nativo;
- Não há amplo suporte por plataformas de CI (Continuous Integration), como Travis ou Jenkins.
Utilizando o conceito de Widgets, permite que sejam criados componentes altamente personalizáveis, oferecendo ao desenvolvedor, maior flexibilidade na construção de UIs (User Interface) mais amigáveis ao usuário final.
Deste modo, o Flutter provê maior flexibilidade na organização da arquitetura de suas aplicações. Embora tal liberdade seja muito valiosa, isso pode resultar em aplicativos com Classes muito grandes, modos de nomeação inconsistentes e arquiteturas incompatíveis com a necessidade ou até mesmo ausentes. Tais tipos de problemas, podem impactar em problemas ao aplicar testes, manutenção e extensões futuras de suas aplicações.
As aplicações de média e grande complexidade vêm tomando a Clean Architecture como uma das melhores soluções, de modo a criar uma arquitetura que seja facilmente escalável, testável e manutenível.
As Camadas de uma Aplicação em Flutter com Clean Architecture
A arquitetura se divide basicamente, nas seguintes camadas:
| API / Local / DB → Remoto / Local (DataSource) → Repositório → Casos de Uso → ViewModel → View |
A arquitetura segue as regras de que, cada camada deve se comunicar apenas com seu componente imediato, desta forma, segue conforme o esquema abaixo:
- A UI (User Interface) pode se comunicar somente, com a ViewModel;
- A ViewModel pode se comunicar somente, com o UseCase;
- O UseCase pode se comunicar somente, com o Repository;
- O Repository pode se comunicar somente, com a DataSource.
Camada de Apresentação (Presentation Layer)
São representadas nesta camada, pelas Views e ViewModels:
- A View é construída, utilizando o conceito de Widgets no Flutter, que descrevem como a interface visual deve ser representado, dado sua configuração e estado;
- A ViewModel possui regras de negócio e desenvolvida com objetivo de armazenar e gerenciar os dados, sendo eles recebidos por meio de requisições de API, banco de dados, etc. A definição das ViewModels podem ser realizadas, utilizando no Flutter, como o BLoC (Business Logic Components), StreamBuilder, FutureBuilder, ChangeNotifier, entre outras ferramentas disponíveis.
Camada de Domínio (Domain Layer)
A composição desta camada, é feita pelos UseCases e Repositories:
- O UseCase é responsável por orquestrar o fluxo de dados das entidades e o direcionar para a regra de negócio, com a finalidade de atingir os objetivos que este é responsável;
- O Repository tem o objetivo de executar a lógica de acesso aos dados, sua responsabilidade é de obter e verificá-los onde estão, e decidir onde procurar a cada momento.
Camada de Dados (Data Layer)
Nesta camada se encontram os dados e de onde eles podem ser acessados.
- O DataSource a fonte de dados propriamente dita, ou seja, é o que a implementação executa, para acessar os dados.
A ideia deste artigo é mostrar que, embora as bibliotecas e componentes constantemente são atualizadas, mas os princípios da Clean Architecture são mantidas, além disso, o desenvolvimento de uma aplicação em Flutter de média e alta complexidade, necessita de uma arquitetura bem estruturada, seguindo os princípios de Clean Code, com o intuito de construir uma aplicação que seja testável e de fácil manutenção.
Sobre o autor
