Apontamentos reunião 19/04/2023

[pedrofgd]

Pontos apontados pela professora durante nossa apresentação:

• TSDB no diagrama de pacotes (mudar para InfluxDB ou algo mais explicativo)
• Avaliar "juntar" o Healthchecker no subsistema de Monitoramento
• Colocar o Cliente no diagrama de pacotes, que é um sistema externo, que interage com o nosso sistema
• Incluir os componentes de Provedores no diagrama de pacotes para interagir com o Requisitor (não está claro o que ele faz)
• Fazer o mesmo para o Mapeador e Configuracoes: deixar mais claro como os componentes se relacionam
• Avaliar mudar o pacote Broker para Orquestrador no diagrama de pacotes
• Avaliar criar um "Health Service", que agrupa melhor os componentes
• Nomear melhor as coisas (exemplo o "Health Service")
• Avaliar o que estamos chamando de Clientes: (1. Um serviço exclusivamente para inicializar, como uma aplicação de "Setup", que chama o inicializador e faz tudo que é necessário, ao invés de deixarmos isso no Cliente, como estava) (2. Aplicação Cliente x Pessoa Cliente) (3.Rotinas de inicialização)
• Ver sobre "Padrões de distribuição de responsabilidades"
• Ver sobre "API Catalog" e "Service Names" (serviço de nomes), para guardar dados sobre quais provedores estão disponíveis. (O que estamos deixando no appsettings.Development.json pode ser movido para um catálogo de APIs - isso precisa ficar claro no diagrama ela arquitetura do sistema) (ela já disse que isso que a gente chamou de "Configurações" é ma verdade um catálogo de APIs)

Sobre o fluxo da requisição no Broker: A requisição tem um contrato genérico e de acordo com o meu QoS eu determino qual o provedor que vai atender a essa chamada. O Broker deve buscar no catálogo de APIs quem implementa esse serviço. "Ô ranqueador, quem que está mais saudável"? "O Broker não precisa falar com configurações, ele já está configurado" (devemos mudar para catálogo de APIs)

Sobre o mapeamento que estamos fazendo antes de enviar a requisição para o provedor: Uma coisa é "Mapear", outra coisa é "Montar". Quando recebemos a requisição, ela sugeriu não "mapear", mas sim montar a requisição para enviar para o provedor ("São expertises diferentes para cada um")

Obs: Sugestão dela para focar e "não fazer tudo". É importante fechar bem o escopo do projeto, se não podemos ter problemas com a banca (exemplo do professor que começou a perguntar sobre a "ISO não sei o que de segurança"). Não valorizar demais certas coisas, para não ser cobrado de coisas que não vamos fazer.

Sugestões:

• Focar no diagrama de requisição passando pelo nosso sistema
• Focar no caminho feliz
• Mostrar bem a estratégia para atualização do ranking
• "Só esses 2 diagramas de sequência que temos que ter no trabalho"
• "Será que o diagrama de sequência é o melhor?", sugeriu usar um diagrama de atividades
• Utilizar labels nos diagramas de sequência (caso formos usar), para descrever de forma geral o que vai ser feito e depois detalhar em outros diagramas mais específicos. O rótulo é uma box no mermaid. Podemos deixar ela vazia e o conteúdo que ficaria na box seria passado para outro diagrama, para facilitar a leitura.
• Dar um nome descente para Configurações, que está dando confusão

Sobre o health check: Avaliar criar um Temporizador, para gerenciar o agendamento dos health checks.

Sobre o ranqueador: ... (tomara que eu não esqueça de escrever depois, que não deu tempo para escrever durante a reunião. Mas ela falou algumas vezes "botar" (atualizar) a ordem dos provedores... fazer o ranqueamento como um processo após receber a requisição. Essa era a ideia original, mas mudamos para ficar mais simplificado, fazendo uma consulta no Ranqueador em toda requisição...)

Lembrar de ver os documentos que ela mandou novamente no grupo do WhatsApp: Para delimitar bem o escopo e escrever o objetivo do trabalho, contando com os requisitos necessários...

Tarefas que ela deixou

• [ ] Fazer esse exercício para escrever a introdução do trabalho
• [ ] "Speedometro" com React para ficar mais visível

[An-225]

Discussão sobre "API Catalog" e "Service Names"

API Catalog

Sobre o API Catalog eu encontrei isso, e parece ser algo bem mais voltado a documentação, assim como o pedro falou:

ref: De, B. (2017). API Management. API Management, 15–28.