Diário de bordo: QRAFZTH

Dia 1

Configuração da estação de trabalho: SDKMAN, IntelliJ IDEA (não obrigatório), Java 17/21, Postman, Docker Desktop

Criação do repositório no Github.

Apresentação do diagrama da solução.

Iniciamos a implementação do serviço de Cadastro utilizando um Mock da persistência em uma lista em memória.

Dia 2

Verbos HTTP: GET (Consulta de dados), POST (Criação de Registros), PUT (Substituição de Registro), PATCH (Alteração parte do Registro), DELETE (Apagar um Registro), HEAD (Requisitar somente o cabeçalho de uma requisição GET) . O verbo OPTIONS utilizado para retornar configurações do serviço.

Sobre o item acima: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Inclusão do endpoint Swagger.

Evoluimos a solução iniciando a implementação das demais classes de serviço e repositório.

Código comitado no github (repo).

Dia 3

Objetivos e referências:

1. Logs: https://mezocode.com/effective-java-logging/.

2. Tratamento de erros: https://mezocode.com/exception-handling-in-java-like-a-pro/

3. CDI: Quarkus CDI, artigo no frescodecamp.org.

4. Testes: Quarkus Tests, artigo do Jean Donato na DZone.

Dia 4

Objectivo: Aprofundar itens da última aula.

Hoje melhoramos bastante o tratamento de erros atravéz de handlers de erros customizados de Validação, Falhas sistêmicas e erros mais genéricos como por exemplo, falhas de infra-estrutura.

Iniciamos a implementação da nossa classe Repository ainda seguindo com a ideia de utilização da persistência em memória (List<>). Dessa forma temos que iniciar com algo muito básico e evoluir naturalmente para o uso do framework e suas capacidades. Esta é a abordagem que estou utilizando aqui no treinamento. Criar o básico e se deparar com a necessidade real do uso das capacidades do Quarkus (Error handlers, Persistência, Mapeamento e etc) de modo que nosso raciocínio nos leve naturalmente ao porque de utilizarmos essas capacidades.

Deixei como tarefa a melhoria/correção dos testes unitários e a depuração do retorno de registro não encontrado que está "estranha".

Até a próxima terça-feira!

Dia 5

Objetivo: Implementar a persistência em banco de dados.

Para isso vamos utilizar o ORM Panache que permite que realizemos operações de banco de dados de forma muito simples. Podemos utilizar dois padrões distintos: Actrive Record e Repository. No primeiro a lógica de manipulação da classe é encapsulada na própria classe, já no repository cria-se uma camada de mediação entre as classes do modelo e a camada de mapeamento deste modelo no banco de dados oferecendo uma interface semelhante a coleções.

Repositório Cadastro Clientes: https://github.com/luizpais/qrafzh-sis-consulta-cadastro

Dia 6

Objetivo: Iniciar a construção do componente de agendamento de Consultas.

Repositório Cadastro de agendamento: https://github.com/luizpais/qrafzth-sis-consulta-agendamento

Dia 7

Objetivo: Finalizar o componente de agendamento e iniciar os componentes dos planos de saude.

Criamos um componente CRUD genérico para poder ser utilizado pelos dois planos de saude em bases de dados diferentes. As customizações serão configuradas no arquivo application.properties de forma que cada plano configure sua porta tcp e seu endereço de banco de dados.

Utilizamos um recurso super prático que é a extensão quarkus-hibernate-orm-rest-data-panache e que permite que vc crie um crud totalmente funcional apenas definindo a entidade e implementando uma interface dessa extensão. São somente e tão somente dois arquivos .java e a referência da extensão no arquivo pom.xml.
Na próxima aula, vamos implementar o fluxo de chamada dos serviços dos convênios e incrementar um pouco a complexidade dos serviços do SIS-Consulta.

Até lá!

Dia 8

Objetivo: Implementar os fluxos de integração com os convênios.

Fluxo de cadastro de cliente: Atendente Pergunta qual o convênio -> Inclui o Cliente informando o código do Convênio -> Verificamos se convenio do Cliente está ativo -> Se sim -> Inclui -> Se não Informa que Cliente Inativo.

Dia 9

Objetivo: Finalizar o fluxo de inclusão de cliente e iniciar a integração do fluxo de agendamento de consulta.

Fluxo de agendamento de consulta: Atendente Pergunta qual o médico -> Dado do código do plano cadastrado -> consulta se médico atende o plano e se está ativo -> se sim -> agenda consulta -> se não -> informa ao cliente.

Dia 10

Objetivo: Finalizar o fluxo de integração da Inclusão com os convênios.

Dia 11

Objetivo: Integrar o agendamento com os planos de saúde.

Dia 12

Objetivo: Criar a pipeline de CI no Github Actions.

Dia 13

Objetivo: Criar o arquivo docker compose para subir os componentes de forma integrada.

1. Criar arquivo docker-compose.yaml.

2. subir no docker via docker compose up -d

3. aguardar finalização

Repositórios

https://github.com/luizpais/qrafzh-sis-consulta-cadastro

https://github.com/luizpais/qrafzth-sis-consulta-agendamento

https://github.com/luizpais/qrafzth-conveniados