• Criar a Entidade Usuário (UserEntity)

  • Vamos iniciar criando a entidade UserEntity que representará tanto o responsável pelo abrigo quanto o doador em nosso sistema. Essa entidade deve contemplar todas as informações pertinentes a ambos e deve incluir o atributo UserProfileType (tipo enumeração) para distinguir entre o responsável do abrigo e o doador.

• Implementar o Repositório para o Usuário (UserRepository)

  • É necessário implementar o repositório que possibilitará as operações de CRUD para a entidade UserEntity. Este repositório deve proporcionar todos os métodos essenciais para a manipulação desses dados.

• Criar o Serviço para o Usuário (UserService)

  • Iremos criar o serviço que será encarregado por tratar as requisições, aplicar as regras de negócio, interagir com o repositório e retornar a resposta correta.

• Criar o Controlador para o Usuário (UserController)

  • Por fim, devemos implementar o controlador que irá tratar das requisições direcionadas ao usuário, seja ele responsável pelo abrigo ou doador, fazendo uso do serviço para fornecer a resposta adequada.

Nesta tarefa, vamos realizar algumas mudanças e adições no código, para melhorar a clareza dos erros e a documentação do projeto. Isto inclui a alteração da constante USER_NOT_FOUND na classe ShelterEntityServiceImpl, a adição de Javadoc na classe UserEntity e a geração dos arquivos Javadoc correspondentes. A seguir, apresentamos os itens em formato de lista To-Do:

• Alterar a constante USER_NOT_FOUND
  • Na classe ShelterEntityServiceImpl, alterar a constante atual USER_NOT_FOUND para:

public static final String USER_RESPONSIBLE_EMAIL_NOT_FOUND_ERROR = "Ops! Não conseguimos encontrar o e-mail do usuário responsável. Por gentileza, tente novamente.";

Esta mudança trará uma melhor expressão do erro ocorrido para os usuários finais.

• Adicionar Javadoc à classe UserEntity

  • A documentação Javadoc deve ser adicionada para a classe UserEntity, abrangendo a definição da classe e a descrição de todos os seus métodos. Os comentários Javadoc devem ser bem escritos e completos, fornecendo um entendimento claro sobre a funcionalidade da classe e seus métodos.

• Geração de Arquivos Javadoc

  • Após a adição dos comentários Javadoc, você deve gerar os arquivos Javadoc usando a ferramenta adequada da sua IDE. Isso garantirá que a documentação do código está atualizada e pronta para referência.

Garantir que essas tarefas sejam cumpridas ajudará a manter a qualidade e a compreensibilidade do código em alto nível.

Nesta tarefa, pretendemos fortalecer o monitoramento da nossa aplicação através do aprimoramento da nossa estratégia de log. Especificamente, adicionaremos logs onde ocorrem exceções na nossa aplicação para permitir um rastreamento mais efetivo de problemas e falhas no sistema. Utilizaremos a anotação @slf4j do projeto Lombok para a implementação dos logs. Veja os passos a seguir:

• Identificar Pontos Onde Ocorrem Exceções na Aplicação

  • O primeiro passo é identificar os pontos no código onde as exceções estão sendo lançadas. Esta identificação é necessária para saber onde precisamos adicionar os logs.

• Implementar Registros (Logs) nos Pontos Identificados

  • Após identificar onde as exceções estão sendo lançadas, implemente logs nestes pontos usando o @slf4j. Certifique-se de que o log fornece informações úteis para a depuração, como o tipo de exceção, a mensagem da exceção e, se possível, a stack trace.

• Testar a Implementação dos Logs

  • Uma vez que os logs tenham sido implementados, é importante testar a implementação. Gere algumas exceções na sua aplicação para confirmar que os logs estão sendo gerados como esperado.

Estaremos focados nesta tarefa na criação de uma classe de serviço dedicada à entidade Donation. A classe de serviço proporcionará um gerenciamento eficiente das operações relacionadas à entidade Donation, funcionando como um canal de comunicação entre nossos controladores e o repositório de dados.

• Criação da Classe de Serviço

  • Precisaremos criar a classe de serviço para a entidade Donation. Esta classe será encarregada de orquestrar as operações relacionadas à entidade Donation em nossos controladores e repositório de dados.

• Definição dos Métodos de Serviço

  • Os métodos de serviço deverão ser definidos para representar as operações que queremos realizar na entidade Donation. Estes podem incluir operações básicas de CRUD, assim como quaisquer operações mais complexas que a entidade Donation possa necessitar.

• Integração com o Repositório de Dados

  • Nosso próximo passo será estabelecer uma integração eficaz entre a classe de serviço e o repositório de dados, permitindo a realização das operações desejadas na entidade Donation.

• Testes da Classe de Serviço

  • Por fim, realizaremos testes em nossa classe de serviço para garantir que todos os métodos estão funcionando como esperado. Estes testes deverão cobrir uma variedade de cenários, assegurando que a classe de serviço para a entidade Donation esteja apta para operar de maneira eficaz.

Nesta tarefa, concentraremos nossos esforços na criação de um novo endpoint que permita aos usuários recuperar detalhes de um abrigo com base no e-mail do usuário responsável. Isso permitirá que os usuários tenham fácil acesso às informações sobre os abrigos dos quais são responsáveis.

• Definição do Novo Endpoint

  • Necessitamos definir um novo endpoint que retornará informações sobre um abrigo com base no e-mail do usuário responsável.

• Implementação do Método de Serviço

  • Implementaremos um novo método de serviço que permitirá a recuperação das informações de um abrigo a partir do e-mail do usuário responsável. Este método comunicará com o repositório de dados para recuperar essas informações.

• Adaptar o Repositório de Dados

  • O repositório de dados precisará ser adaptado para suportar a recuperação de informações do abrigo com base no e-mail do usuário responsável. Isso pode envolver a implementação de um novo método de consulta.

• Testes do Novo Endpoint

  • Para assegurar que tudo funciona conforme esperado, precisaremos realizar testes em nosso novo endpoint. Estes devem abordar uma variedade de cenários para validar que o processo de recuperação das informações do abrigo está funcionando corretamente.

Nesta tarefa, abordaremos a importância da documentação do código por meio do Javadoc. Isto inclui a verificação da ausência de Javadoc no código e, caso ausente, deve ser adicionado. Além disso, iremos gerar o Javadoc através da IDE para posteriormente publicá-lo na branch main após o lançamento da Release 1.0.0.

• Verificação da Ausência de Javadoc no Código

  • Devemos percorrer toda a base de código, verificando todos os métodos e classes para garantir que tenham Javadoc. Caso seja detectada a ausência de Javadoc, deverá ser adicionado, a fim de garantir que o código seja bem documentado e fácil de entender.

• Geração do Javadoc via IDE

  • Após a verificação e eventual adição de Javadoc, iremos gerar o Javadoc da aplicação usando as ferramentas disponíveis na IDE. Este passo é importante para assegurar que toda a documentação do código esteja acessível e atualizada.

• Publicação do Javadoc na Branch main

  • Por fim, vamos publicar o Javadoc gerado na branch main do repositório após o lançamento da Release 1.0.0. Isso garantirá que a documentação esteja disponível para todos os membros da equipe e para qualquer usuário ou colaborador que acessar nosso repositório.

Neste trabalho, temos como objetivo a criação da interface DonationServiceContract no pacote CORE, além de adaptar a classe DonationEntityServiceImpl do pacote REST para utilizar o DonationServiceContract. Com esta ação, alinhamos nossa aplicação aos princípios da Arquitetura Hexagonal, que busca separar as responsabilidades do domínio de negócio do contexto da aplicação em outras camadas como infraestrutura.

• Criar a Interface DonationServiceContract no CORE

  • Primeiro, devemos criar a interface DonationServiceContract no pacote CORE. Esta interface é a que será utilizada pelo pacote REST, permitindo uma separação efetiva das responsabilidades de nosso código.

• Refatorar DonationEntityServiceImpl para Utilizar DonationServiceContract

  • Com a interface DonationServiceContract criada, o próximo passo é adaptar a classe DonationEntityServiceImpl do pacote REST para fazer uso desta interface. É importante garantir que todas as operações anteriormente realizadas por DonationEntityServiceImpl agora sigam o contrato definido por DonationServiceContract.

• Verificação de Interfaces e Contratos

  • Após a refatoração, é importante verificar se todos os métodos presentes em DonationServiceContract estão corretamente implementados em DonationEntityServiceImpl. Os contratos devem ser seguidos à risca para manter a consistência do código.

• Atualização da Documentação

  • Finalmente, atualize a documentação do projeto para refletir as mudanças implementadas. As informações sobre a criação da interface DonationServiceContract e a adaptação de DonationEntityServiceImpl devem ser convenientemente registradas para futuras referências.

Nesta tarefa, iremos implementar a consulta à API externa do ViaCEP para obter informações de endereço a partir de um CEP fornecido. A inclusão desses dados oferecerá uma maneira eficiente de conseguir informações precisas e completas sobre o endereço, melhorando assim a precisão dos dados de endereço de nossos abrigos.

• Implementar a Chamada à API Externa

  • Devemos implementar uma chamada HTTP para a API do ViaCEP (https://viacep.com.br/ws/93218270/json) na classe ShelterEntityService. Essa chamada deve ser feita no formato GET, passando o CEP como parâmetro.

• Tratamento da Resposta da API

  • Ao receber a resposta da API, devemos mapear o JSON retornado para nossos objetos de endereço. Vamos tratar qualquer possível exceção que possa ocorrer durante a chamada e informar o usuário quando algo der errado.

• Integrar com o Fluxo Existente de Criação de Abrigo

  • Após obter as informações de endereço da API do ViaCEP, devemos integrar essas informações ao processo existente de construção do abrigo, garantindo que o endereço recuperado esteja associado ao abrigo construído.

• Testes Unitários

  • Iremos garantir que a nova funcionalidade esteja funcionando corretamente. Para isso, vamos criar testes unitários para testar a chamada à API em diferentes cenários.

Este é um resumo de nossos objetivos nesta tarefa. Ao final, esperamos que o serviço seja capaz de consultar a API do ViaCEP para obter informações de endereço para um CEP fornecido, e que essas informações sejam incorporadas na criação de novos abrigos em nossa aplicação.

• Payload da API ViaCEP:

{
  "cep":"93218-270",
  "logradouro":"Avenida Mauá",
  "complemento":"",
  "bairro":"Centro",
  "localidade":"Sapucaia do Sul",
  "uf":"RS",
  "ibge":"4320008",
  "gia":"",
  "ddd":"51",
  "siafi":"8901"
}

Nesta tarefa, trabalharemos na criação de um novo endpoint que retorne uma lista de abrigos, incluindo uma funcionalidade de paginação. A inclusão de paginação nos permitirá gerenciar eficientemente grandes quantidades de dados e melhorar a experiência do usuário, permitindo-lhes navegar pelos dados de uma maneira mais controlada.

• Definição do Novo Endpoint

  • Precisamos definir um novo endpoint que será responsável por retornar uma lista de abrigos. Este endpoint deverá suportar a funcionalidade de paginação.

• Implementação do Método de Serviço

  • Será necessário implementar um novo método de serviço que recuperará a lista de abrigos do repositório de dados. Este método deve levar em consideração os parâmetros de paginação.

• Adaptação do Repositório de Dados

  • Nossos dados precisam ser adaptados para suportar a recuperação paginada de abrigos. Isso envolve adicionar funcionalidade ao nosso repositório de dados para handle com solicitações paginadas.

Esta tarefa envolve a implementação de versionamento nos endpoints da nossa aplicação. O versionamento permite que façamos alterações significativas nos nossos endpoints sem interromper os serviços já em uso. Isso será feito adicionando prefixos de versão (/v1, /v2, etc.) aos nossos endpoints. Segue a lista de tarefas para esta issue:

• Estudar os Padrões de Versionamento

  • Comece esta tarefa pesquisando e estudando os diferentes padrões de versionamento para APIs REST. Isto inclui padrões como Versionamento pela URI, pelo cabeçalho Accept , pelo cabeçalho personalizado e pelo cabeçalho Content-Type. Escolha o padrão que mais se adequa às necessidades da nossa aplicação.

• Implementar o Versionamento nos Endpoints

  • Depois de escolher um padrão de versionamento, implemente-o em nossos endpoints. Isso envolve a adição de um prefixo de versão (como /v1 ou /v2) à URI de cada endpoint.

• Testar os Endpoints Versionados

  • Após implementar o versionamento, verifique se ele funciona como esperado. Faça isso testando cada endpoint versionado and garantindo que ele responde da maneira correta.

• Criar a Entidade Abrigo (ShelterEntity)

  • Vamos criar a Entidade ShelterEntity que representará o abrigo em nosso sistema. Essa entidade deve conter todas as informações relevantes ao abrigo.

• Implementar o Repositório para Abrigo (ShelterRepository)

  • Precisamos implementar o Repositório que irá permitir as operações de CRUD para a Entidade ShelterEntity. No repositório devem constar todos os métodos necessários para a manipulação desses dados.

• Criar Testes de Integração para o ShelterRepository

  • Nesta etapa, deve-se criar testes de integração para o ShelterRepository. Esses testes terão como objetivo garantir que as operações de banco de dados para o gerenciamento dos Abrigos estão funcionando como esperado. Deve-se testar todas as operações de CRUD (Create, Read, Update, Delete), bem como quaisquer outras operações específicas que sejam importantes para o funcionamento do ShelterRepository.

Nesta issue, iremos abordar as modificações nos pipelines de CI/CD para gestão das imagens Docker. Vamos adicionar condições nos workflows de CI (Continuous Integration) para garantir que a construção e envio de imagens Docker para o Docker Hub aconteçam somente quando um PR (Pull Request) for mesclado nas branches main e release/*. Essas modificações irão melhorar a consistência e segurança do nosso processo de CI/CD.

• Adicionar Condição no Workflow de CI para o arquivo ci-prod.yaml
  • É necessario modificar o arquivo de workflow ci-prod.yaml para adicionar uma condição de validação na etapa Build and push. Essa condição irá verificar se um PR para a branch main foi mesclado e, somente nesse caso, a construção e envio da imagem Docker será realizada.

      - name: Build and push
        id: docker_build
        if: github.event.pull_request.merged == true && github.ref == 'refs/heads/main'
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: diegoneves/conectar-doacoes:latest
          build-args: |
            DB_NAME=${{ env.DB_NAME }}
            DB_PASSWORD=${{ env.DB_PASSWORD }}
            DB_USERNAME=${{ env.DB_USERNAME }}

• Adicionar Condição no Workflow de CI para o arquivo ci-hlg.yaml
  • Semelhante ao item anterior, vamos modificar o arquivo de workflow ci-hlg.yaml para adicionar uma condição de validação na etapa Build and push. Desta vez, a condição deverá verificar se um PR foi mesclado em qualquer branch do tipo release/* e, se verdadeiro, a construção e envio da imagem Docker será realizada.

      - name: Build and push
        id: docker_build
        if: github.event.pull_request.merged == true && github.ref == 'refs/heads/release/*'
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: diegoneves/conectar-doacoes:${{ env.BRANCH_NAME }}
          build-args: |
            DB_NAME=${{ env.DB_NAME }}
            DB_PASSWORD=${{ env.DB_PASSWORD }}
            DB_USERNAME=${{ env.DB_USERNAME }}

Ambas as tarefas acima irão garantir um controle mais refinado sobre nosso processo de CI/CD, aumentando a eficiência e a segurança de nossas operações.

• Criar o Serviço para Abrigo (ShelterService)

  • Nesta etapa, será necessário construir a camada de serviço do módulo de Abrigos. Esta classe de serviço (ShelterService) será responsável por implementar a lógica de negócios relacionada à gestão de Abrigos e por comunicar-se diretamente com a camada de repositório.

• Criar o Controlador para Abrigo (ShelterController)

  • Em seguida, devemos implementar o Controlador para os Abrigos (ShelterController). Este controlador será responsável por receber, processar e responder às requisições HTTP relacionadas à gestão de Abrigos. Para isso, o controlador irá interagir com a classe de serviço (ShelterService) para realizar as operações necessárias.

• Criar os Testes Unitários para o Serviço e o Controlador

  • Ao final, é importante desenvolver testes unitários para as classes de serviço e controlador. Esses testes irão assegurar que as funcionalidades do módulo de Abrigos estejam funcionando corretamente e de acordo com o esperado. Além disso, os testes ajudarão a identificar e corrigir possíveis bugs antes que eles afetem o software em produção.

Na presente tarefa, nosso objetivo é aprimorar as mensagens de erro de retorno da API geridas pela classe ControllerExceptionHandler.java localizada no pacote rest. Especificamente, pretendemos otimizar as mensagens de erro do enum ExceptionDetails para torná-las mais amigáveis ao usuário.

Também planejamos inserir um novo atributo do tipo Integer para o ExceptionDetails com o propósito de direcionar a correspondência entre exceções personalizadas e mensagens de erro. Cada número inteiro irá representar uma mensagem específica, estabelecendo um método intuitivo e eficaz para rastrear e corrigir exceções.

Nossas ações serão divididas da seguinte maneira:

• Melhoramento das Mensagens de Erro

  • Analisaremos as mensagens de erro já existentes e faremos as modificações necessárias para torná-las mais amigáveis, claras e informativas.

• Adicionar Atributo Integer ao ExceptionDetails Enum

  • Implementaremos um atributo do tipo Integer para o ExceptionDetails enum para fazer referência às mensagens de erro.

• Mapear as Mensagens de Erro aos Valores do Enum

  • Estabeleceremos a correspôndencia entre os valores do novo atributo Integer e as respectivas mensagens de erro.

• Diferenciar Mensagens de Erro para Gêneros Feminino e Masculino

  • Valores ímpares representarão as mensagens de erro para o gênero feminino e valores pares farão referência àquelas para o gênero masculino.

• Adaptação do ControllerExceptionHandler.java

  • Faremos a necessária adaptação da classe ControllerExceptionHandler.java para acomodar as novas funcionalidades introduzidas.

Nossas ações visam aprimorar a apresentação e gestão de mensagens de erro, proporcionando assim uma experiência de usuário aprimorada.

Neste trabalho, o objetivo é criar a interface AddressServiceContract no pacote CORE e adaptar a classe AddressEntityServiceImpl do pacote REST para utilizar o AddressServiceContract. Seguindo os preceitos da Arquitetura Hexagonal, esse procedimento objetiva distinguir o domínio central da aplicação das camadas de infraestrutura.

• Criar a Interface AddressServiceContract no CORE

  • Iniciamos criando a interface AddressServiceContract no pacote CORE. Essa será a interface que será implementada pelo serviço na camada de REST, estabelecendo um contrato para o comportamento desejado.

• Refatorar AddressEntityServiceImpl para Utilizar AddressServiceContract

  • Após termos a interface definida, precisamos refatorar a classe AddressEntityServiceImpl para implementar AddressServiceContract. Isso implica em certificar que todos os métodos exigidos pela interface estão corretamente implementados na classe de serviço.

• Revisão de Interfaces e Contratos

  • Na sequência, realizamos uma revisão completa das interfaces e contratos envolvidos. Cada método definido em AddressServiceContract deve estar corretamente implementado em AddressEntityServiceImpl, para que nosso código siga à risca o contrato estabelecido.

• Atualização da Documentação

  • Por fim, a documentação do projeto deve ser atualizada para refletir as mudanças realizadas. Todo o processo, da criação da interface AddressServiceContract à refatoração da classe AddressEntityServiceImpl, deve estar devidamente documentado.

Neste issue, iremos abordar a questão sobre a verificação e correção dos itens assinalados pelo SonarCloud em nosso projeto. Isto inclui a compreensão dos problemas apontados, a correção desses problemas e a garantia de que nosso código atenda aos padrões de qualidade estabelecidos. Enfrentar esses problemas irá melhorar a qualidade do nosso código e garantir que nosso sistema esteja seguro e eficiente.

• Compreensão dos Problemas Assinalados pelo SonarCloud

  • Vamos analisar os relatórios do SonarCloud para entender os problemas em nosso código que necessitam de correção.

• Correção dos Problemas

  • Devemos abordar cada problema levantado e implementar as corrigir necessárias para resolver os problemas identificados.

• Assegurar que o Código Atenda aos Padrões de Qualidade

  • Após as correções, devemos fazer a verificação do código para garantir que todos os problemas foram resolvidos e que o código atende aos padrões de qualidade.

• Reanálise pelo SonarCloud

  • Por fim, devemos fazer uma reanálise pelo SonarCloud para garantir que todos os itens destacados foram satisfatoriamente abordados e corrigidos.

Nesta tarefa, propomos a refatoração da classe CustomException para promover a consistência na ordem dos parâmetros de seu construtor. O objetivo é alinhar a ordem dos parâmetros do construtor da classe CustomException com as classes que a estendem. Esta melhoria contribuirá para a organização do código, facilitará o entendimento da estrutura das classes e promoverá a manutenção futura do software.

• Análise da Classe CustomException e Classes Filhas

  • Analise a classe CustomException e as classes que a estendem para entender a atual ordem dos parâmetros em seus construtores.

• Refatoração da Classe CustomException

  • Refatore o construtor da classe CustomException para seguir a ordem dos parâmetros que foi identificada nas classes filhas.

• Ajuste nas Classes Filhas

  • Após a alteração na classe CustomException, ajuste todas as classes que a estendem para que sigam a nova ordem dos parâmetros no construtor.

• Testes e Validação

  • Após a refatoração, realize testes para garantir que todas as classes estão funcionando conforme esperado após as alterações, e que as exceções estão sendo lançadas e tratadas corretamente.

• Documentação

  • Atualize qualquer documentação associada à classe CustomException e às classes filhas para refletir as alterações feitas durante a refatoração. Garanta que a nova ordem dos parâmetros esteja devidamente explicada na documentação.

No progresso para a liberação da versão release/1.1.0 da nossa aplicação, precisamos garantir que a documentação esteja atualizada e completa. Isto inclui a atualização do arquivo Release_Notes.md com as informações mais recentes sobre as modificações da aplicação, e a geração do Javadoc com a documentação do código atualizado. A realização destas tarefas proporcionará uma descrição completa e precisa das modificações na versão release/1.1.0 para a equipe de desenvolvimento e os stakeholders.

• Atualizar o Arquivo Release_Notes.md

  • O arquivo Release_Notes.md deve ser atualizado com todas as informações das novas funcionalidades, correções de bugs e melhorias realizadas para a versão release/1.1.0. Certifique-se de detalhar todas as modificações de modo claro e preciso, para proporcionar uma compreensão completa do que foi alterado nesta versão.

• Gerar o Javadoc Atualizado

  • O Javadoc do projeto deve ser gerado com base no código da versão release/1.1.0. Se certifique de que todos os comentários do código estejam atualizados e completos, pois eles serão usados para gerar a documentação do Javadoc. A documentação do Javadoc é essencial para entender como as classes do código interagem entre si e como utilizar corretamente as funcionalidades da aplicação.

Para melhorar a robustez de nossa aplicação, esta tarefa se concentra na adição de uma etapa de validação antes da execução do método createShelter da service ShelterEntityServiceImpl.java. Esta validação assegurará que o objeto Request não seja nulo antes que a operação de criação seja executada. A seguinte é uma lista de tarefas a serem concluídas.

• Adicionar Validação no Método createShelter
  • Modifique o método createShelter na classe ShelterEntityServiceImpl.java para incluir uma verificação preliminar que valide se a request é nula. Se o objeto Request for nulo, um erro específico deve ser lançado.

Esta issue envolve a implementação de três classes de configuração: CorsConfig, OpenApiConfig e WebSecurityConfig no nosso projeto. Aqui está uma breve descrição de cada classe:

• CorsConfig: Esta classe será responsável por gerenciar a configuração CORS (Cross-Origin Resource Sharing) da nossa API. Ela garantirá que os clientes possam interagir com a nossa API a partir de diferentes domínios, proporcionando a necessária flexibilidade, mas ao mesmo tempo mantendo os dados seguros.

• OpenApiConfig: Esta classe será encarregada de lidar com a documentação da nossa API. Ela vai adotar a especificação OpenAPI, um padrão para definir APIs. Além de ajudar a gerar e expor a documentação da API, ela facilitará o consumo e entendimento de nossa API pelos usuários.

• WebSecurityConfig: Esta classe será o ponto principal de nossa configuração de segurança. Baseada no Spring Security, ela vai definir como a autenticação e autorização serão gerenciadas. Seu objetivo é garantir que apenas usuários autorizados tenham acesso a recursos específicos.

A importância destas classes é melhorar a estrutura geral, a segurança, e a facilidade de uso de nossa API. A implementação deve seguir as melhores práticas e manter a extensibilidade para futuras necessidades. Se houver quaisquer dúvidas ou sugestões, por favor, sinta-se à vontade para discuti-las nesta issue.

Na presente tarefa, abordaremos as melhorias no gerenciamento de exceções na aplicação. Isto inclui a implementação de uma estrutura robusta e centralizada para o manejo de exceções, a padronização das mensagens de erro através de uma Data Transfer Object (DTO) e a consolidação de todas as mensagens de erro em uma enumeração. A implementação dessas melhorias permitirá um melhor controle sobre as exceções lançadas e proporcionará uma experiência consistente em toda a aplicação.

• Criar uma Classe para Gerenciamento das Exceções

  • Usaremos a anotação @RestControllerAdvice para criar uma classe global para lidar com todas as exceções que possam ocorrer em nossa aplicação.

• Criar uma DTO para Padronizar as Mensagens das Exceções

  • Vamos criar uma Data Transfer Object (DTO), chamada ExceptionDTO, para padronizar as mensagens de erro retornadas quando uma exceção é lançada.

• Criar um Enum para Centralizar as Mensagens de Erro

  • Criaremos uma enumeração, chamada ExceptionDetails, para armazenar todas as nossas mensagens de erro padrão. Isso nos permitirá ter todas as nossas mensagens de erro em um só lugar e promoverá a consistência em toda a aplicação.

Nesta tarefa, abordaremos a criação de uma Prova de Conceito (POC) para a utilização de QR Code na confirmação de doações. Isso inclui a geração do QR Code pelo doador no momento de definir uma lista de doações, e o uso desse QR Code pelo receptor para confirmar o recebimento das doações. A implementação dessa POC irá permitir validarmos a viabilidade desta funcionalidade antes de procedermos com o seu desenvolvimento completo.

• Criar Mecanismo para Geração de QR Code

  • Este mecanismo será responsável por gerar o QR Code contendo as informações relevantes ao definir uma lista de doações.

• Interface de Leitura de QR Code para Confirmação

  • Deverá ser criada uma interface que permita ao receptor a leitura do QR Code gerado pelo doador, com o objetivo de confirmar o recebimento das doações.

• Lógica de Confirmação de Recebimento

  • Implementar a lógica que será executada ao confirmar o recebimento das doações por meio da leitura do QR Code.

• Validação da POC

  • Por fim, a POC deve ser validada em um ambiente controlado para garantir que a geração e leitura do QR Code, bem como a confirmação do recebimento das doações, funcionem conforme esperado.

Dependências:

• [REST] - Implementação de Lista de Doações para Usuário com Perfil de Doador .

Para aprimorar nossas operações de recuperação de usuários, precisamos criar um endpoint (GET) que permita recuperar um usuário fornecendo seu email. Isso facilitará a recuperação de informações do usuário e tornará o processo mais eficiente. Discutiremos as etapas específicas envolvidas na implementação deste endpoint.

• Definição do Novo Endpoint

  • Necessitamos definir um novo endpoint GET. Este endpoint deverá permitir a recuperação do usuário quando fornecido um email como parâmetro.

• Implementação do Método de Serviço

  • Implementaremos um novo método de serviço para recuperar o usuário pelo email. Este método deverá interagir com o repositório de dados para recuperar as informações do usuário.

• Adaptar o Repositório de Dados

  • Adaptaremos o repositório de dados para permitir a recuperação do usuário por email. Isso envolve a criação de um novo método que realize esta tarefa.

A aplicação necessita de novas funcionalidades para melhorar sua eficácia e servir de forma mais completa à comunidade. Essas funcionalidades são as seguintes:

• Cadastro de Responsável pelo Abrigo:
  Temos a necessidade de implementar uma funcionalidade para registrar os responsáveis pelos abrigos. Isso incluiria o nome do responsável, o contato e possivelmente algumas informações adicionais relevantes.
• Cadastro de Doador:
  Para acompanhar as doações recebidas e permitir comunicações futuras, precisamos implementar uma funcionalidade para registrar doadores. Isso incluiria o nome do doador, informações de contato e um histórico das doações feitas.

A adição dessas novas funcionalidades de cadastro refletiria positivamente em nosso serviço, dando-nos a capacidade de manter um registro mais preciso e minucioso de nossas operações e facilitando o gerenciamento de nossas relações com abrigos e doadores.

Esta tarefa visa fortalecer as regras de negócio da nossa aplicação através da adição de uma nova regra ao serviço de criação de Abrigo (ShelterEntityServiceImpl.java). A nova regra irá prevenir a criação de um novo abrigo caso o responsável informado já tenha vínculo com outro abrigo, utilizando o e-mail como atributo de validação. Adicionalmente, o perfil do usuário (UserProfile) deve ser obrigatoriamente 'Beneficiário' para que o mesmo seja aceito como Responsável pelo Abrigo. As seguintes etapas serão necessárias para completar esta tarefa.

• Identificar o Método que Cria um Novo Abrigo

  • Localize o método na classe ShelterEntityServiceImpl.java responsável pela criação de um novo abrigo. Este será o local onde a nova regra de negócio será aplicada.

• Implementar a Regra de Negócio

  • Modifique o método de criação de um novo abrigo para verificar se o responsável informado já tem vínculo com outro abrigo e se o perfil do usuário é 'Beneficiário' antes de criar o abrigo. Se o responsável já estiver vinculado a um abrigo ou se o perfil do usuário não for 'Beneficiário', o sistema deve lançar uma exceção ou retornar uma resposta de erro indicando que a criação do abrigo não é permitida.

• Testar a Regra de Negócio

  • Depois de implementar a nova regra de negócio, faz-se necessário testar a implementação para garantir que funciona como esperado. Certifique-se de que quando um responsável que já tem vínculo com um abrigo ou cujo perfil do usuário não é 'Beneficiário' tenta criar um novo abrigo, a aplicação responde corretamente.

Nesta tarefa, focaremos em refatorar o código da aplicação para melhorar a manutenibilidade. Isso inclui remover importações não utilizadas, excluir atribuições não utilizadas e corrigir declarações Javadoc problemáticas. A execução dessas melhorias aumentará a eficiência do código, facilitará a compreensão e aumentará a qualidade geral do software.

• Remover Importações Não Usadas

  • Faremos uma inspeção em todo o código-fonte da aplicação para identificar e remover todas as importações de classes que não estão sendo utilizadas. Isso inclui aquelas importações que estão sendo sombreadas por uma importação posterior, bem como aquelas que simplesmente não estão sendo referenciadas em nenhum lugar no código.

• Remover Atribuições Não Utilizadas

  • Uma inspeção semelhante será realizada para identificar e remover quaisquer atribuições não utilizadas de objetos ou variáveis. Essas são instâncias onde um valor é atribuído a uma variável, mas a variável nunca é utilizada. Remover essas atribuições irá melhorar a eficiência e a clareza do código.

• Corrigir Declarações Javadoc com Problemas

  • Por último, mas não menos importante, procederemos à revisão de todas as declarações Javadoc na aplicação. Corrigiremos quaisquer problemas encontrados, incluindo descrições imprecisas, tags de parâmetros faltantes ou incorretas, e quaisquer outros problemas de formatação ou conteúdo.

Nesta tarefa, nosso objetivo será a criação de um novo endpoint que irá receber uma requisição contendo os dados do e-mail do responsável pelo abrigo e os detalhes da doação. Este endpoint, então, registrará a doação para o respectivo abrigo. Isso possibilitará um processo uniforme e automatizado para a realização de doações para os abrigos.

• Definição do Novo Endpoint

  • Precisaremos definir um novo endpoint que será capaz de receber as informações da doação e do e-mail do responsável pelo abrigo.

• Implementação do Método de Serviço

  • Iremos implementar um novo método de serviço que se encarregará de processar os dados recebidos e registrar a doação para o abrigo em questão. Esse método deve estar apto para interagir com o repositório de dados para realizar tais operações.

• Adaptar o Repositório de Dados

  • O repositório de dados necessitará ser adaptado para suportar as operações de registro de doações. Isso poderá envolver a criação de novos campos para armazenar os dados das doações e modificações nas queries de consulta.

• Cadastro de Abrigo:
  Precisamos de uma funcionalidade para registrar novos abrigos na aplicação. Isso incluiria o nome do abrigo, o endereço, o responsável associado, um histórico das doações recebidas e possivelmente outras informações relevantes.

Nesta tarefa, daremos ênfase à funcionalidade que permitirá aos usuários com perfil de doador (DONOR) criar uma lista de itens disponíveis para doação (Donations). Isso facilitará a gestão dos itens que o doador pretende doar, proporcionando um controle mais eficiente sobre esses materiais. Além disso, a implementação dessa funcionalidade melhorará a experiência do usuário na plataforma.

• Definir a Estrutura de Dados da Lista de Doações

  • Para armazenar as doações de forma eficiente e coerente, é necessário definir uma estrutura de dados apropriada. Esta estrutura de dados poderá incluir informações relevantes, como a descrição do item, a quantidade, o estado do item, entre outros.

• Criar Funções CRUD para a Lista de Doações

  • Depois de definir a estrutura de dados, é necessário implementar as operações de CRUD (Criar, Ler, Atualizar, Deletar). Estas funções permitirão ao doador gerenciar a sua lista de doações.

• Integração com a Interface do Usuário

  • A funcionalidade de gerenciamento de lista de doações deve ser integrada com a interface do usuário. Isso irá permitir que os doadores interajam de forma intuitiva com a sua lista de doações.

• Testar a Funcionalidade

  • Por fim, a nova funcionalidade deve ser testada em todos os casos de uso relevantes para garantir que funciona como esperado.

Nesta tarefa, vamos implementar um recurso similar a um "Carrinho de Compras" para gerenciar as doações. O usuário com perfil de doador poderá adicionar itens que deseja doar nesse "carrinho". Ao finalizar o processo, um QR Code será gerado para referenciar o "carrinho" e os itens nele contidos. A implementação desta funcionalidade proporcionará uma gestão eficiente do processo de doação.

• Desenvolver o Recurso "Carrinho de Compras"

  • Criaremos um recurso que simula um "Carrinho de Compras", permitindo que o usuário adicione, remova ou modifique itens que ele pretende doar.

• Integrar a Função de Gerar QR Code

  • Após a finalização do "Carrinho de Compras", um QR Code será gerado. Este QR Code será uma representação única do "carrinho" e dos itens nele contidos.

• Funcionalidade para Fechar o Carrinho

  • Iremos desenvolver uma funcionalidade que encerre o processo de inclusão de itens no "carrinho", disparando a geração do QR Code.

• Testar a Implementação

  • A funcionalidade completa deve ser testada em diversos cenários para garantir sua corretude e eficiência.

Dependências:

• [REST] - Prova de Conceito (POC) para Geração de QR Code para Confirmação de Doações

• Adicionar Atributo ID nas Classes Donation e Address

  • Adicionar o atributo do tipo String "id" nas classes "Donation" e "Address" localizadas no pacote "core". Este atributo servirá como identificador único para cada instância dessas classes.

• Criar Factories para Donation e Address

  • Implementar factories para as classes "Donation" e "Address". As fábricas devem garantir a geração do atributo "id" para cada nova instância das classes.

• Adicionar Testes de Unidade para o Novo Atributo

  • Criar testes de unidade que garantam o funcionamento correto do novo atributo "id". Esses testes devem cobrir todas as possíveis interações com o novo atributo.

• Refatorar os Mappers no Package Rest

  • Refatorar os mappers existentes no pacote "rest" para refletir a adição do novo atributo em "Donation" e "Address". Certifique-se de que o atributo "id" seja mapeado corretamente durante a conversão de entidades em DTOs e vice-versa.

• Refatorar os Testes de Unidade caso Haja Necessidade

  • Revisar e refatorar os testes de unidade existentes para garantir a compatibilidade com as alterações feitas nas classes "Donation" e "Address". Qualquer teste que falhe devido à adição do novo atributo deve ser corrigido.

Nesta tarefa, iremos focar em adaptar a classe UserEntityServiceImpl do pacote REST para receber e utilizar o UserServiceContract do núcleo do projeto. Esta tarefa é fundamental para respeitar os princípios fundamentais da Arquitetura Hexagonal, que preza pelo isolamento do domínio de negócio central, e sua abstração em relação ao código de infraestrutura.

• Refatorar UserEntityServiceImpl para Utilizar UserServiceContract

  • Faça as alterações necessárias na classe UserEntityServiceImpl para que esta utilize o UserServiceContract. Atente-se para substituir todos os pontos onde a lógica atual pode estar atrelada diretamente ao pacote REST.

• Revisar Interfaces e Contratos

  • Revise todas as interfaces e contratos envolvidos para garantir que todas as funções presentes no UserServiceContract estão devidamente implementadas em UserEntityServiceImpl. Caso necessário, ajuste os contratos e interfaces para melhor se adequar às necessidades da aplicação.

• Documentação

  • Atualize a documentação do projeto para refletir as mudanças realizadas na classe UserEntityServiceImpl e no uso do UserServiceContract. Lembre-se de documentar as premissas e qualquer alteração importante de fluxo no sistema.

Nesta tarefa, iremos realizar uma refatoração no enum ExceptionDetails de nossa aplicação, com o objetivo de adequar os HttpStatus em conformidade com as respectivas mensagens de erro. Esta alteração proporcionará uma maior consistência e coerência entre as mensagens de erro e seus respectivos códigos de status HTTP.

• Análise do Enum ExceptionDetails

  • Realize uma análise completa do enum ExceptionDetails, revisando todas as mensagens e seus respectivos HttpStatus associados.

• Refatoração de HttpStatus

  • Após a revisão, inicie a refatoração dos HttpStatus. Assegure-se de que cada HttpStatus esteja de acordo com a natureza da sua mensagem de erro correspondente.

• Validação e Testes

  • Após a refatoração, valide se todas as mensagens de erro estão retornando os HttpStatus corretos. Realize testes em cenários variados para garantir que as alterações estão funcionando conforme o esperado.

• Documentação

  • Atualize a documentação do código para refletir as mudanças realizadas neste processo de refatoração. Garanta que as alterações estejam devidamente documentadas para facilitar a futura manutenção do código.

• Criação de Interfaces para Repositórios 🗞️

  • Novas interfaces para os repositórios serão criadas. Essas interfaces irão definir os métodos essenciais relacionados ao manejo dos dados das entidades no banco de dados.

• Desenvolvimento de Interfaces para Serviços ⚙️

  • Serão desenvolvidas as interfaces que definirão os contratos dos serviços. Estes serviços conterão a lógica de negócio relacionada às entidades.

• Implementação de Funções para a Criação de Entidades 🛠️

  • Implementação de funções para a criação das entidades no sistema. Estas funções proporcionarão a interação com as entidades, incluindo sua criação.

Com este trabalho, iremos ajustar a classe ShelterEntityServiceImpl do pacote REST para utilizar o ShelterServiceContract provido pelo CORE do nosso projeto. Desta forma, abarcamos os benefícios advindos da Arquitetura Hexagonal, que visa isolar e proteger o domínio central de negócio de eventuais alterações na camada de infraestrutura.

• Refatorar ShelterEntityServiceImpl para Utilizar ShelterServiceContract

  • Precisamos adaptar a classe ShelterEntityServiceImpl para que ela faça uso do ShelterServiceContract. Certifique-se de substituir todos os pontos onde a lógica atual pode estar ligada diretamente ao pacote REST.

• Análise de Interfaces e Contratos

  • É importante analisar todas as interfaces e contratos envolvidos para assegurar que todas as funções presentes no ShelterServiceContract estão devidamente implementadas em ShelterEntityServiceImpl. Providencie os ajustes nos contratos e interfaces caso a aplicação necessite.

• Atualização da Documentação

  • A documentação do projeto deve ser atualizada para refletir as mudanças feitas na classe ShelterEntityServiceImpl e na utilização do ShelterServiceContract. Lembrando sempre de documentar as premissas e quaisquer modificações relevantes no fluxo do sistema.

Nesta tarefa, estaremos focando na criação de uma classe de serviço para a entidade Address. A adição desta classe de serviço permitirá um gerenciamento mais eficaz das operações relacionadas ao Address, fornecendo uma camada adicional de abstração entre nossos controladores e o repositório de dados.

• Implementação da Classe de Serviço

  • Vamos precisar implementar a classe de serviço para a entidade Address. Esta classe será responsável por gerir as transações relacionadas à Address, facilitando a interação entre os controladores e o repositório de dados.

• Definir os Métodos de Serviço

  • Nossos métodos de serviço representarão as operações que queremos realizar na entidade Address. Estes podem incluir operações de CRUD básicas, bem como outras operações complexas que possam ser exigidas pela entidade Address.

• Integração com o Repositório de Dados

  • Vamos assegurar que nossa classe de serviço possa interagir com o repositório de dados, permitindo a realização das operações desejadas na entidade Address.

• Testes da Classe de Serviço

  • Por fim, precisaremos realizar testes em nossa classe de serviço para garantir que todos os métodos funcionem corretamente. Estes devem abordar uma variedade de cenários a fim de certificar a funcionalidade completa da classe de serviço para a entidade Address.

Nessa tarefa focaremos em melhorias na documentação e atualização da versão da nossa API. Estas ações incluem a geração de JavaDoc para fornecer documentação consistente e fácil de entender para as nossas classes e métodos, a inclusão das notas de release no arquivo Markdown e a atualização da versão da API na OpenApiConfig.

• Gerar JavaDoc

  • Geraremos o JavaDoc para todas as classes e métodos relevantes do nosso projeto. O JavaDoc é uma ferramenta poderosa que nos permite criar uma documentação consistente e fácil de entender diretamente no código-fonte.

• Inserir Release Notes

  • As notas de release serão adicionadas no arquivo Markdown da aplicação. Este documento deverá conter todas as informações relevantes sobre as mudanças implementadas na nova versão da API, incluindo novos recursos, melhorias e correções de bugs.

• Alteração da Versão da API na OpenApiConfig

  • Atualizaremos a versão da API de 1.0.0 para 1.2.0 na configuração OpenApiConfig do nosso projeto. Essa ação refletirá a versão atual do nosso sistema na documentação gerada automaticamente pelo Swagger.

Cada uma dessas tarefas tem como objetivo melhorar a qualidade da nossa documentação e garantir que a versão da nossa API esteja atualizada e consistente em todos os lugares.