Aplicação back-end utilizando Java e Spring Boot, baseada em um teste para vaga de Desenvolvedor Back-end Java pela empresa TIVIA. O presente tem como objetivo o cadastro de Beneficiários e seus respectivos Documentos, a relação entre as duas entidades é de 1 para muitos respectivamente.
- Cadastrar um beneficiário junto com seus documentos;
- Listar todos os beneficiários cadastrados;
- Listar todos os documentos de um beneficiário a partir de seu id;
- Atualizar os dados cadastrais de um beneficiário;
- Remover um beneficiário;
- Implementar autenticação/autorização para acesso aos endpoints;
- Fornecer a documentação dos endpoints utilizando Swagger;
Criar uma aplicação utilizando Java e Spring Boot que forneça uma API REST para manter o cadastro de beneficiários de um plano de saúde.
# Clone este repositório
git clone https://github.com/caetanojpo/tivia-test.git
# Inicie a aplicação com uma IDE de sua preferência e digite no terminal
mvn clean install
mvn spring-boot:run
#Acesse o seguinte endereço no navegador
http://localhost:8080/swagger-ui/index.html
- Java 17
- Arquitetura baseada em Clean Architecture
- Criação de Annotations para validação de dados
- Swagger
- Banco H2
- Testes unitários
- Spring Security
- BCryptPasswordEncoder
Trata-se de desenvolvimento de API Rest, primordialmente baseada em duas Entidades, quais sejam Beneficiário e Documento, com os desafios elencados em tópico anterior. As entidades foram modeladas com os seguintes atributos, em uma relação de 1 para muitos na ordem que segue:
Beneficiario
- id;
- nome;
- telefone;
- dataNascimento;
- dataInclusao;
- dataAtualizacao.
Documento
- id;
- tipoDocumento;
- descricao;
- dataInclusao;
- dataAtualizacao.
Para o desenvolvimento foi escolhida a utilização de arquitetura baseada em Clean Architecture, com o intuito de fazer o uso de boas práticas de programação e deixar o core da aplicação isolado, deixando o uso de frameworks na camada de infraestrutura.
A criação de um novo Beneficiário pode, ou não, ser realizada em conjunto com a sua lista de Documentos, caso o Beneficiario seja cadastrado sem documentos há um endpoint especifico para o cadastro e vinculação de Documentos a um Beneficiario especifico.
Dada a opção de aplicar o sistema de autorização/autenticação no projeto, tomei a liberdade de modelar uma entidade User para lidar com toda a lógica de autenticação.
A documentação da aplicação está disponível no swagger e, também, disponilizei alguns registros em cada tabela, principalmente na User, para facilitar a obtenção de um Bearer Token.
POST localhost:8080/api/users/login
{
"email":"teste@teste.com",
"password": "!123Teste"
}
Para o desenvolvimento do projeto tentei fazer ao máximo o uso de boas práticas. A nível de código podemos ver a utilização de alguns princípios do SOLID. Tais como o uso de single responsibility principle, que pode ser observado na implementação de classes consistentes, pequenas, e que possuem um unico objetivo para a sua existência. Assim como a inversão de depêndencia, utilização de Beans, e uso de interfaces coesas, para fazer o bom uso de seus métodos quando implementadas.
O projeto possui algumas características de arquitetura limpa, ele é dividido nas seguintes camadas:
- DOMAIN: O coração da aplicação, onde estão contidos modelos, repositorio e exceptions gerais.
- INFRA: Camada que possui a responsabilidade de conversar com o mundo externo, aqui temos os controllers, implementação da database, assim como as configurações do projeto e definições de beans.
- USECASE: É a responsável por conter as regras crucias de negocio, são aquelas regras que sempre existiram na empresa e eram executadas de forma manual.
Foram escritos testes unitários para as controladoras das 3 entidades.
- Construir a aplicação em microsserviços, o que possibilita a utilização de um Broker, como RabbitMQ, para lidar com as trocas de mensagens entre os serviços, isso melhoraria a estruturação, manutenção e confiabilidade de todo o sistema.
- Migrar a utilização de bancos e outras ferramentas para o Docker.
- A depender da composição e necessidade do projeto, poderia se estudar a utilização de um banco NoSQL, como MongoDB, a fim de trazer flexibilidade e dinamismo para a estruturação dos documentos.
- Utilização do redis para se trabalhar com cache e evitar que o usuário envie a mesma senha por diversas vezes, derrubando servidor.
- A entidade Documento possui o campo "descricao", contudo o mesmo leva a uma confusão, pois pode não remeter à ideia de se tratar do número do documento, seria adequado, por boas práticas, alterar o nome do campo ou acrescentar um novo.
Criado por João Pedro Caetano.
