Projeto final: Sales Management

O desafio

Construa o Sales Management, uma aplicação corporativa para gestão de produtos, clientes e pedidos. O objetivo não é reproduzir uma tela específica, mas demonstrar que você consegue transformar requisitos em uma solução coesa, segura e operável.

Use a base criada ao longo dos módulos. Faça commits pequenos e mantenha a aplicação executável em cada marco.

Escopo funcional

Autenticação e usuários

• Login por e-mail e um provedor social no ambiente de laboratório.
• Logout e restauração segura de sessão.
• Perfis admin, supervisor e seller.
• Rotas e ações protegidas também no backend/regras.

Dashboard

• Receita total, quantidade de pedidos, clientes ativos e produtos cadastrados.
• Estados loading, empty, success e failure.
• Layout adaptado a telefone, tablet e desktop/web.

Produtos e clientes

• Listagem, pesquisa, criação, edição e validação.
• Imagem de produto com progresso e tratamento de falha.
• Paginação ou carregamento incremental.
• Registro de atualização para sincronização.

Pedidos

• Seleção de cliente e produtos.
• Quantidade, valor unitário e total calculado pelo domínio.
• Validação contra pedido vazio ou quantidade inválida.
• Estado de pedido e atualização de estoque em operação consistente.

Continuidade e notificações

• Cache local das consultas importantes.
• Indicação clara de dado desatualizado ou operação pendente.
• Estratégia documentada para conflito e reconexão.
• Notificação de evento de negócio sem payload sensível.

Arquitetura esperada

lib/
  core/
    environment/
    error/
    network/
    observability/
  features/
    auth/
    dashboard/
    products/
    customers/
    orders/
  main.dart

Cada feature deve separar domain, data e presentation quando a complexidade justificar. Não crie camadas vazias apenas para obedecer ao desenho; registre decisões e exceções no README.

Qualidade obrigatória

• dart format e flutter analyze sem erro.
• Testes unitários para regras de pedido e autorização.
• Testes de widget para login, produto e estados de erro.
• Ao menos uma jornada integrada.
• Nenhum segredo ou token em código, logs ou repositório.
• Regras de segurança testadas quando usar Firebase.
• Pipeline executando qualidade e gerando artefato.

Entregáveis

1. Repositório com histórico de commits compreensível.
2. README com requisitos, instalação, ambientes e decisões.
3. Diagrama simples das dependências.
4. Aplicação executável com dados de demonstração.
5. Relatório de testes e limitações conhecidas.
6. Vídeo ou sequência de imagens mostrando a jornada principal.

Critérios de avaliação

Roteiro de conclusão

1. Defina o recorte mínimo e escreva os casos de uso.
2. Construa uma fatia vertical: login, produto, pedido.
3. Adicione persistência e integrações atrás de contratos.
4. Cubra regras críticas com testes.
5. Valide experiência em diferentes tamanhos e falhas.
6. Automatize o gate de qualidade.
7. Revise segurança, documentação e demonstração.

Reflexão final

Ao concluir, registre três decisões que melhoraram o sistema e uma que você mudaria. Engenharia madura não é fingir que a primeira solução foi perfeita; é conseguir explicar o contexto, o compromisso assumido e o próximo passo.

Quando o projeto estiver executável, testado e documentado, marque esta etapa. Você terá uma aplicação que conecta os fundamentos do Flutter a um processo real de engenharia de software.

Defesa técnica do projeto

Além da demonstração, prepare uma conversa de 15 minutos que responda:

1. Qual regra de negócio está protegida no domínio e por qual teste?
2. Qual fronteira permite trocar API, persistência ou Firebase?
3. Como a interface representa carregamento, ausência, falha e operação offline?
4. Qual dado sensível foi deliberadamente excluído de logs e armazenamento?
5. Que falha o pipeline consegue impedir antes da entrega?
6. Qual decisão você revisaria se o produto crescesse dez vezes?

Execute o gate a partir de um checkout limpo e registre versões e artefatos:

flutter --version
flutter pub get
dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test --coverage
flutter build <target> --release

Não apresente apenas “todos os comandos ficaram verdes”. Explique a evidência produzida por cada etapa e qual risco ainda permanece fora dela. Consulte a referência de comandos e conceitos para revisar a toolchain antes da defesa.