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.

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