Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W wiki
  • 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
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Informativo para Imigrantes
  • wiki
  • Wiki
  • arquitetura

Last edited by Vitor Felipe Leitenski Delela Nov 24, 2023
Page history
This is an old version of this page. You can view the most recent version or browse the history.

arquitetura

  • Linguagem: Java 11

  • Framework: Spring Boot

  • Presentation layer (Controller): Layer da aplicação onde são apresentandos os endpoints da aplicação, sendo dentre deles os controllers, Data Transfer Objects (DTOs) e entidades.

  • Business logic layer (Service): Layer da aplicação de services onde está presente a lógica da aplicação, pesquisas para o mapa, tratamento e processamento dos dados, pesquisas das restrições e entre outras coisas.

  • Data access layer (Repository): Layer onde é realizada a a comunicação com o banco de dados, fazendo buscas, criações de objetos, mudanças de dados no geral.

Módulos do Sistema

  • config: contém as configurações do Swagger.
  • controller: é o ponto de entrada do backend, onde ficam definidos os endpoints da aplicação, ou seja, os caminhos após o endereço do servidor como /user e qual o tipo de chamada o endereço irá receber GET, POST, PUT ou DELETE.
  • dto: possui os objetos utilizados para transportar dados entre as camadas.
  • entity: possui os mapeamentos para a tabela do banco de dados.
  • enums : possui as enumerações utilizadas nas DTOS ou entidades.
  • message: centraliza todas as mensagens que são enviadas ao frontend.
  • repository: centraliza toda a comunicação com o banco de dados, passando os parâmetros adequados para as funções desejadas.
  • security: define configurações de acesso aos endpoints e a autenticação de usuários cadastrados.
  • service: centraliza todas as nossas regras de negócio, utilizando o repository para fornecer os dados do banco e realizar as validações.
  • util: possui classes que tem métodos que são utilizados em diversos services, como por exemplo, o Validations.java, que contém validações de campos de um objeto. Nessa camada também ficam as exceptions personalizadas e os handlers dessas exceptions.

Git Workflow

Branches

Requisitos

Antes de criar uma branch nova certifique-se de que:

  • Está na branch principal dev.

Criando branchs

Primeiro atualize sua branch local, com o seguinte comando

git pull

Para criar uma nova branch, execute o comando:

git checkout -b <nomeDaBranch>

Como padrão para nomes de branches, foi decidido o seguinte:

<código da tarefa>-<nome da tarefa utilizando camelCase quando necessário>

Por exemplo:

git checkout -b US01-tipoUsuario

Assim que a branch for criada execute o seguinte comando:

git push --set-upstream origin <nome da branch>

Dessa forma a branch será enviada para o repositório remoto no GitLab

Commits

Antes de fazer o commit é necessário preparar as alterações. Temos 2 maneiras de fazer isso:

O comando git add . prepara todas as alterações que foram feitas localmente sejam adicionadas ao commit:

git add .

O comando git add <nomeDoArquivo> prepara apenas as alterações do arquivo informado sejam adicionadas ao commit.

git add <nomeDoArquivo>

Após adicionar as alterações é necessário commitar elas usando o comando

git commit -m "comentario-do-commit"

Faça commit sempre que alguma funcionalidade for alterada, assim garantindo um método fácil de recuperação do código (caso necessário).

Após o commit, compartilhe as alterações no repositório remoto utilizando o comnado git push

git push 

Merge Requests

Assim que uma tarefa for finalizada execute o seguinte comando:

git pull origin dev

O mesmo irá garantir que sua branch está atualizada com a branch dev (caso haja conflitos, resolva-os) e realize um commit com o seguinte nome:

Merge branch 'dev' into '<nome da branch>'

Depois de estar com a sua branch remota pronta para merge, crie um Merge Request no GitLab e preencha com as seguintes informações:

  • Source Branch: Sua branch.
  • Target Branch: branch dev.
  • Título: <código da tarefa>-<nome da tarefa utilizando camelCase quando necessário>
  • Descrição: Descrição da tarefa e/ou das mudanças no código

Assim que for criado o Merge Request, passe o card da sua tarefa no trello para "Review" e avise um AGES 3, AGES 4 ou líder da Squad.

Clone repository
  • Documentação endpoints
  • Mockups
  • arquitetura
  • banco_dados
  • codigo
  • design_mockups
  • escopo
  • Home
  • processo
  • qualidade
  • utilizacao