💡Flutter Leap Overview (Descontinuado)

O Flutter Leap, é um repositório base que mantemos, contendo a arquitetura de pastas propostas para os nossos projetos, as libs que utilizamos com frequência, alguns componentes e funcionalidades.

Architecture overview

Temos aqui uma imagem explicando de maneira diagramal o uso da arquitetura que usamos atualmente no nosso projeto leap, desde a separação de pastas e lógica, conexão com API e a build de CI/CD.

Descrição técnica

Aqui temos um pequeno resumo da descrição técnica da imagem acima, a qual é mais aprofundada no vídeo abaixo.

O projeto é estruturado seguindo um modelo de Clean Arch e os princípios do SOLID.

Possui as camadas data, domain e presentation. Dentro de data temos as models e as datasources. As models são as modelagens dos recursos da API, utilizando o json_serializable para efetuar este mapeamento. Estes modelos são utilizados em todo o projeto. As datasources são as implementações dos repositórios. É aqui onde as implementações das chamadas da API são feitas, através do retrofit. Na camada domain estão as interfaces dos repositórios e as implementações dos use cases.

Cada repositório é uma classe abstrata, possuindo apenas a assinatura dos métodos. Um use case é uma funcionalidade isolada do projeto. É aqui onde as requests são chamadas, por exemplo. Na presentations temos as interfaces dos use cases, views, components e as stores. A interface de um use case é apenas a assinatura daquele use case. As views são as telas do aplicativo em si.

A pasta components existe para uma melhor organização dos componentes. A store, disponibilizada pelo mobX, é a classe para controle da reatividade da tela. Uma tela pode depender de mais de uma store, e uma store pode ser utilizada em mais de uma tela. É dentro da store que os use cases são chamados. Cada implementação sempre depende de uma abstração, portanto a implementação de um use case depende da interface de um repositório e a store depende de uma interface de um use case.

A injeção destas dependências acontece utilizando o get_it. Dentro da pasta utils há um arquivo setup_get_it, onde são descritos qual implementação cada abstração deve injetar quando chamada. Portanto, se uma tela precisa de um dado da API, o seguinte fluxo deve ser feito: a assinatura desta chamada deve ser escrita em algum repositório; a implementação desta função deve ser feita no respectivo datasource; uma interface de use case e sua implementação devem ser criados; a tela deve ser criada; esta tela precisa depender de uma store; na store devem ser feitos as actions e observables para utilizar o usecase.

Video overview

Temos um vídeo explicando principalmente a arquitetura do nosso leap, e algumas das funcionalidades