🍃Arquitetura Recomendada pelo FLUTTER

Nesta documentação, unimos os conceitos de teoria e prática para ajudar você a estruturar seu aplicativo Flutter de forma modular, escalável e fácil de manter, seguindo as recomendações do time do Flu

DOCUMENTAÇÃO BASEADA EM:

doc oficial: https://docs.flutter.dev/app-architecture

video diego antunes: https://www.youtube.com/watch?v=_pPUqNXudXg&ab_channel=Prof.DiegoAntunes

com help do chat gpt para resumir melhor as informações que encontrei

1. Princípios Fundamentais

Antes de entrarmos nos detalhes técnicos, é importante entender os pilares que guiam a arquitetura recomendada:

Separação de Responsabilidades (Separation of Concerns)

• Divida a aplicação em camadas independentes, cada uma com responsabilidades bem definidas.

• Exemplo: A lógica de exibição de dados (UI) deve ser separada da lógica de negócios e da lógica de acesso a dados.

Fonte Única da Verdade (SSOT - Single Source of Truth)

• Cada tipo de dado deve ter uma única fonte de verdade, que centraliza a responsabilidade pelo estado e pelas alterações desse dado.

• Geralmente, isso é feito nos Repositórios.

Fluxo Unidirecional de Dados (UDF - Unidirectional Data Flow)

• O estado flui do Data Layer (camada de dados) para o UI Layer (camada de interface).

• Eventos do usuário fluem na direção oposta, da UI para o Data Layer.

UI como Função do Estado

• A interface é declarativa: ela reflete diretamente o estado atual da aplicação.

• Quando o estado muda, a UI é automaticamente reconstruída.

---

2. Estrutura Arquitetural

A arquitetura é composta por camadas principais e, opcionalmente, uma camada intermediária para lógica mais complexa.

Camadas Principais

1. Camada de UI (Apresentação)

   • Responsável por interagir com o usuário.

   • Exibe os dados e captura eventos (toques, entradas de texto).

   • Contém as Views (Widgets) e ViewModels.

2. Camada de Dados

   • Gerencia os dados da aplicação, seja de fontes locais (bancos) ou remotas (APIs).

   • Contém os Repositórios e Services.

Camada Opcional: Lógica (Domínio)

• Encapsula regras de negócios complexas em Use Cases.

• Abstrai a interação entre as camadas de UI e dados, reduzindo a complexidade em ViewModels.

---

3. Prática: Componentes Arquiteturais

Agora vamos detalhar os componentes dentro de cada camada e como eles interagem.

UI Layer: Views e ViewModels

1. Views

   • São os Widgets que compõem a interface.

   • Não devem conter lógica de negócios, apenas lógica simples como:

     • Mostrar ou esconder widgets.

     • Lidar com animações ou layout.

   • Exemplos: LoginView, ProfileView.

2. ViewModels

   • Fazem a ponte entre os dados e a View.

   • Suas responsabilidades incluem:

     • Buscar dados nos repositórios.

     • Transformar os dados no formato necessário para a UI.

     • Expor callbacks para eventos do usuário (ex.: cliques em botões).

---

Data Layer: Repositórios e Services

1. Repositórios

   • São a fonte única da verdade para cada tipo de dado.

   • Responsáveis por:

     • Combinar dados de múltiplos serviços.

     • Cachear dados.

     • Tratar erros.

   • Exemplo: UserRepository.

2. Services

   • Isolam a lógica de acesso a fontes externas, como APIs ou banco de dados.

   • Não possuem estado nem lógica de negócios.

   • Exemplo: AuthService para autenticação.

---

Domain Layer (Opcional): Use Cases

• Encapsula regras de negócios complexas.

• Exemplo: Um LoginUseCase pode validar credenciais, fazer login e salvar tokens localmente.

---

4. Fluxo Prático de Dados

A arquitetura segue um fluxo unidirecional de dados:

1. O usuário interage com a View (ex.: clica em um botão).

2. A View aciona um callback na ViewModel.

3. A ViewModel chama métodos em um ou mais Repositórios.

4. Os Repositórios acessam os Services para buscar ou enviar dados.

5. Os Repositórios retornam os dados transformados para a ViewModel.

6. A ViewModel atualiza o estado, que é refletido na View.

---

5. Exemplo de Estrutura

Aqui está um exemplo prático de como organizar as pastas do seu projeto:

lib/
├── features/
│   ├── login/
│   │   ├── data/
│   │   │   ├── repositories/
│   │   │   ├── services/
│   │   ├── domain/
│   │   │   ├── use_cases/
│   │   ├── presentation/
│   │   │   ├── views/
│   │   │   ├── view_models/
├── shared/
│   ├── utils/
│   ├── widgets/

6. Boas Práticas

• Mantenha as Views "magras": A lógica deve estar na ViewModel ou nas camadas inferiores.

• Teste cada camada separadamente:

  • Mocks para Repositórios e Services facilitam os testes.

• Evite Dependências Diretas: Use injeção de dependências para desacoplar as classes.

---

Com essa abordagem, você garante que seu aplicativo seja escalável, fácil de manter e siga padrões modernos de arquitetura no Flutter! 🚀