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

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)