Fazer uma revisão minunciosa do código do back end, e realizar melhorias caso necessário
Como ?
Pontos de Melhoria:
[x] Nomenclatura DTOS
Proposta Nomenclatura:
Adapters --> .<input/output>.dto
Core --> .<input/output>.dto
Mesmo que seja igual, a ideia é ter a duplicidade, para caso quando for escalado o sistema tenhamos uma maior consistencia de arquitetura, e maior isolamento dos casos de uso tanto nos adapters e no core
[x] #140 - StandBy: Avaliar necessidade
[x] Revisar STATUS CODE das respostas dos endpoints, levando em consideração os padrões de uma API Restful: 99%
[ ] Revisar os retornos dos endpoints, levando em consideração os padrões de uma API Restful: 99%
[x] Otimização dos scripts de inicialização do projeto
[x] Rever no prisma o datatype de registry no schema de Patient Appointment Registry (!)
[x] Checar se tem mais algum endpoint que recebe data como query params ou no body
[x] Corrigir erro retornado do método updatePatientAppointmentRegistry no banco em memória
[x] Corrigir retornos dos metodos de update para retornar o dado atualizado
[x] #141 - Erro não identificado. Se necessário será retomada a atividade
[x] Padronizar atribuição dos ids nos parametros de rota ( id para entidade e .id para as relações)
[x] Verificar nomes dos casos de teste e2e
[ ] Verificar duplicação de código dos DTOs (input core vs output controllers)
O que ?
Como ?
updatePatientAppointmentRegistryno banco em memóriaPorque ?
Pair Programming ?
Referencias