Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • O onyva-back
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ONYVA
  • onyva-back
  • Wiki
  • Organização e Referências de Arquitetura

Last edited by Andrews Souza Nov 09, 2020
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Organização e Referências de Arquitetura

Este projeto adota uma arquitetura baseada em camadas, onde cada camada tem sua responsabilidade, e sempre a camada mais alta irá se comunicar com a camada mais baixa.

Camada de interfaces de entrada (pasta interfaces)

Esta pasta contém todos os pontos de entrada para a aplicação. É o início, é aqui que estarão os controllers e rotas do Express.

Camada de aplicação (pasta app)

A camada de aplicação é responsável por fazer o intermédio entre a interface e a lógica de negócio. Nesta camada podemos criar operações e serviços que se comunicarão com a infraestrutura (Banco de dados ou outros serviços externos).

Camada de infraestrutura (pasta infra)

Esta é a camada mais baixa. Na camada de infraestrutura sempre terá a comunicação com o que está fora da aplicação, como banco de dados, serviços de email e comunicação direta com frameworks.

Injeção de Dependência

Ideia central desse padrão é que cada dependência de um objeto que pode (e faz sentido) ser desacoplada deve ser injetada para torná-la mais flexível, reutilizável e facilmente testável. Neste projeto a injeção de dependências funciona usando a biblioteca Awilix. Artigo sobre esta biblioteca (escrito pelo autor), parte 1 , parte 2 e parte 3 . Para as injeções nos controladores, usamos o adaptador Express Awilix.

Repository

Este padrão parte do princípio de que não devemos tocar diretamente no banco de dados. Então temos repositórios que tratam da persistência internamente e os injetamos nas instâncias de operações e serviços que desejam utiliza-la. Referência.

Notificações

O projeto utiliza o serviço de Cloud Messaging do Firebase para enviar push notifications aos usuários. Para isso, foi criado uma conta com os dados:

  • email: [email protected]
  • senha: onyva2020

Ponto de atenção

O projeto possui rotas que permite o envio de notificação para múltiplos usuários. Porém, o serviço do Firebase possui uma limitação de 500 usuários por notificação. Em fase de desenvolvimento e testes isso não é um problema, porém quando em produção, isso pode causar erros. Uma possível solução é dividir os usuários alvos em grupos de 500 e chamar o serviço de notificação para cada grupo.

Notificação mensal

O sistema possui uma notificação mensal, onde pede-se ao usuário proprietário que ele atualize a kilometragem do veículo. O dia do mês e o horário dessa notificação são definidos através de uma expressão cron no arquivo schedulerOperation.js. Aqui está um guia para expressões cron

Clone repository
  • Home
  • Organização e Referências de Arquitetura
  • Rodando localmente (development)