Backend

Esta página centraliza informações sobre o repositório Backend do projeto Sem Barreiras.

Sumário

• Organização do repositório
• Padrões de código
  • Nomenclatura de classes
  • Nomenclatura de variáveis
  • Nomenclatura de métodos
• Tratamento de exceções
• Documentação do Swagger

Organização do repositório

O projeto Spring Boot do repositório de Backend do projeto está organizado seguindo um padrão Controller-Service-Repository, e esse padrão está refletido na organzação de pacotes do projeto. Optou-se por esse padrão pois, ainda que este padrão possa trazer problemas como acoplamento de regras de negócio e tecnologias de ORM (sendo estes problemas que poderiam ser resolvidos com um padrão de arquitetura limpa), ele segmenta o código em camadas visando uma separação de preocupações/responsabilidades (Separation of concerns). Além disso, é um padrão fácil de entender para desenvolvedores que não possuem muita experiência com Spring Boot ou com o desenvolvimento de APIs em geral.

Diante disso, os pacotes do projeto estão divididos da forma abaixo:

• 📁 config: Configurações personalizadas da aplicação (ex.: configuração da conexão com o banco de dados, declaração de Beans).
• 📁 controller: Expõe pontos de entrada para comunicação com o mundo exterior. Neste projeto, gerencia a API REST da aplicação, incluindo responsabilidades como autenticação e autorização, e delega o processamento de lógica de negócio para a camada de services.
• 📁 dto: Classes utilizadas para transferir dados entre camadas de uma aplicação (não são entidades, são apenas classes que modelam essas informações a serem trafegadas na aplicação).
  • 📁 request: DTOs para dados de entrada das requisições.
  • 📁 response: DTOs para dados de resposta das requisições.
• 📁 exception: Exceções personalizadas da aplicação.
• 📁 model: Entidades do negócio.
• 📁 repository: Encapsula a lógica de acesso ao banco de dados para buscar e persistir dados.
  • 📁 impl: Classes que implementam as interfaces em repository.
• 📁 service: Implementação da lógica de negócio (interfaces). Se necessário buscar ou salvar dados, delega isso para a camada de repository.
  • 📁 impl: Classes que implementam as interfaces em service.
• 📁 util: Classes e métodos utilitários (ex.: formatação de datas)

Padrões de código

Nomenclatura de classes

Classes do projeto devem ser nomeadas em inglês e seguir o padrão PascalCase, ou seja, devem iniciar com letra maiúscula e cada palavra ou abreviatura no meio da frase também deve iniciar com letra maiúscula. Por exemplo:

• UserController ✔
• User_Controller ❌
• Usercontroller ❌
• userController ❌

Além disso, com exceção do pacote model, os nomes das classes devem refletir o pacote onde elas estão localizadas, conforme o exemplo abaixo:

• 📁 config: ExemploConfig
• 📁 controller: ExemploController
• 📁 dt.request: ExemploRequest
• 📁 dt.response: ExemploResponse
• 📁 exception: ExemploException
• 📁 repository: ExemploRepository
• 📁 service: ExemploService
• 📁 util: ExemploUtil

Nomenclatura de variáveis

Variáveis devem ser nomeadas em inglês e seguir o padrão camelCase, ou seja, devem iniciar com letra minúscula e cada palavra ou abreviatura no meio da frase deve iniciar com letra maiúscula. Por exemplo:

• isAdmin ✔
• isadmin ❌
• is_Admin ❌
• IsAdmin ❌

A exceção são as variáveis constantes (que devem ser estáticas e finais) e enums, que devem seguir o padrão SCREAMING_SNAKE_CASE, onde as palavras no meio da frase são separadas por underscores (_) e as letras devem ser todas maiúsculas. Por exemplo: API_BASE_URL

Além disso, para criar um código limpo e fácil de entender e realizar a manutenção depois, sempre nomeie as variáveis de forma que fique claro o seu propósito/o tipo de informação que ela possui. Para isso, seguem algumas dicas:

• Evitar abreviações.
• Para variáveis booleanas, não nomear apenas com substantivos, para deixar claro que é um booleano. Por exemplo, ao invés de "publish", usem "isPublished".
• Criar variáveis fáceis de pronunciar.
• Evitar dar nomes muito parecidos para duas variáveis.
• Não usar números mágicos. Se existir algum número que precisa ser utilizado no código, criar uma variável para este número para deixar claro o que ele significa.

Nomenclatura de métodos

Variáveis devem ser nomeadas em inglês e seguir o padrão camelCase, ou seja, devem iniciar com letra minúscula e cada palavra ou abreviatura no meio da frase deve iniciar com letra maiúscula. Por exemplo:

• findUserByName ✔
• finduserbyname ❌
• find_User_By_Name ❌
• FindUserByName ❌

Além disso, para facilitar a leitura do código, em uma classe os métodos sempre devem estar organizados na ordem abaixo:

1. Métodos public
2. Métodos protected
3. Métodos private

Tratamento de exceções

TODO

Documentação do Swagger

TODO