Refinamento Arquitetural - Sprint 3

Visão Geral da Arquitetura

A Sprint 3 concentra-se na implementação dos fluxos centrais do sistema: a Solicitação de Feedback por parte dos colaboradores e a Resposta de Feedback pelos avaliadores externos. Esta fase é crucial para materializar o core business da aplicação, envolvendo a criação e orquestração de funcionalidades nos microserviços de FeedbackRequestService e FeedbackResponseService, além de interações significativas com o Frontend, API Gateway, e o serviço de notificações por e-mail.

A arquitetura continuará seguindo os princípios de microserviços, Domain-Driven Design (DDD), e comunicação via API RESTful, garantindo escalabilidade, manutenibilidade e clareza nas responsabilidades de cada componente.

Componentes Arquiteturais Chave para Sprint 3

Durante a Sprint 3, os seguintes componentes serão desenvolvidos ou terão suas funcionalidades expandidas:

1. Microserviço de Solicitação de Feedback (FeedbackRequestService - Java/Spring Boot)

Responsável por todo o ciclo de vida da solicitação de feedback:

• Criação e Edição de Solicitações: Permitir que colaboradores criem e editem rascunhos de solicitações, adicionando perguntas personalizadas e indicando avaliadores externos.
• Gestão de Status: Controlar os status da solicitação ("em criação", "pendente aprovação", "aguardando respostas", "finalizado", "rejeitado").
• Submissão para Aprovação: Enviar a solicitação para o PDM correspondente.
• Processo de Aprovação/Rejeição: Permitir que PDMs aprovem ou rejeitem solicitações, com justificativa para rejeição.
• Geração de Hash para Formulários: Criar um identificador único (hash) para cada formulário, a ser usado nos links enviados aos avaliadores.
• Validações de Negócio:
  • Mínimo de 3 perguntas personalizadas.
  • Mínimo de 2 e máximo de 9 avaliadores.
  • E-mail de avaliador não pode ser do domínio @ciandt.com.br.
  • Colaborador só pode criar novo formulário 6 meses após finalização do último.
• Notificações: Enviar e-mails para PDMs (nova solicitação), colaboradores (status da solicitação) e avaliadores (convite para feedback).

2. Microserviço de Resposta de Feedback (FeedbackResponseService - Java/Spring Boot)

Responsável por gerenciar o processo de resposta dos avaliadores externos:

• Autenticação do Avaliador:
  • Validar e-mail do avaliador (não pode ser @ciandt.com.br).
  • Gerar e enviar um código de acesso único por e-mail.
  • Validar o código de acesso informado.
• Exibição do Formulário: Apresentar o formulário de feedback (perguntas) com base no hash da solicitação.
• Validação de Prazo: Verificar se o formulário está dentro do período de 3 meses para resposta (a partir da data de aprovação do PDM).
• Coleta e Armazenamento de Respostas:
  • Permitir que o avaliador responda às perguntas ou indique "não sabe avaliar".
  • Salvar respostas como rascunho.
  • Finalizar e submeter a avaliação.
• Notificações: Informar o colaborador quando um feedback for finalizado (se for o último avaliador).
• Atualização de Status: Sinalizar ao FeedbackRequestService quando uma resposta é submetida para que o status geral da solicitação possa ser atualizado.

3. Frontend (Next.js) - Papéis e Interações

Interfaces de usuário específicas serão desenvolvidas para:

• Colaborador:
  • Listar suas solicitações de feedback (com status e ações).
  • Criar novo formulário de solicitação (adicionar perguntas, avaliadores).
  • Editar formulários em rascunho ou rejeitados.
  • Excluir solicitações (conforme regras de status).
  • Visualizar o status da aprovação e das respostas.
• PDM (People Development Manager):
  • Listar solicitações pendentes de sua aprovação.
  • Analisar detalhes da solicitação (perguntas, avaliadores).
  • Aprovar ou rejeitar solicitações, adicionando comentários se rejeitar.
• Avaliador Externo:
  • Página de "login" para inserir e-mail e receber código de acesso.
  • Página para inserir código de acesso.
  • Formulário de feedback para responder às perguntas.
  • Opções para salvar rascunho ou finalizar avaliação.

4. Serviço de E-mail

Um componente crucial para as notificações. Pode ser um serviço interno dedicado ou a integração com um provedor de e-mail externo. Será utilizado para:

• Enviar código de acesso para avaliadores.
• Notificar PDMs sobre novas solicitações de feedback.
• Notificar colaboradores sobre o status de suas solicitações (aprovada, rejeitada, respondida).
• Enviar convites com o link (contendo o hash) do formulário para os avaliadores.

Diagrama de Componentes da Sprint 3

Decisões Arquiteturais da Sprint 3

1. Autenticação de Avaliador Externo via Código de Acesso por E-mail:

   • Decisão: Avaliadores externos se autenticam fornecendo seu e-mail (previamente cadastrado na solicitação) e um código de acesso único enviado para esse e-mail.
   • Justificativa: Mecanismo simples e de baixo atrito para o avaliador, que não precisa criar uma conta formal. Garante que apenas o dono do e-mail convidado possa responder. Evita que colaboradores internos (@ciandt.com.br) respondam, pois o sistema já valida o domínio no cadastro e pode reforçar no login.
   • Implicações: Forte dependência do serviço de e-mail para o fluxo de resposta. Necessidade de gerenciar a geração, envio, validade e unicidade dos códigos de acesso.

2. Hashing de ID de Formulário para Links Externos:

   • Decisão: O identificador da solicitação de feedback usado nos links enviados aos avaliadores será um hash não sequencial e difícil de adivinhar, em vez de um ID numérico direto.
   • Justificativa: Aumenta a segurança por obscuridade, dificultando que terceiros tentem adivinhar URLs de formulários válidos.
   • Implicações: O FeedbackRequestService deve gerar e armazenar este hash. O FeedbackResponseService (e o Frontend) utilizarão este hash para buscar e identificar os formulários.

3. Validação de Prazo de Resposta (3 meses):

   • Decisão: As respostas de feedback só serão aceitas se submetidas dentro de um período de 3 meses a contar da data de aprovação da solicitação pelo PDM.
   • Justificativa: Garante que o feedback coletado seja temporalmente relevante para o desenvolvimento do colaborador.
   • Implicações: O FeedbackResponseService precisa consultar a data de aprovação da solicitação (provavelmente via FeedbackRequestService ou diretamente do banco de dados compartilhado/replicado) e compará-la com a data atual antes de permitir a resposta.

4. Notificações por E-mail para Eventos Chave:

   • Decisão: Utilizar e-mails para notificar os usuários (colaboradores, PDMs, avaliadores) sobre eventos importantes no ciclo de vida do feedback.
   • Justificativa: Mantém os usuários informados e engajados no processo. É um meio de comunicação padrão e esperado para tais interações.
   • Implicações: Necessidade de um serviço de e-mail confiável e resiliente. As operações de envio de e-mail devem ser, preferencialmente, assíncronas para não bloquear os fluxos principais da aplicação.

5. Separação Funcional entre FeedbackRequestService e FeedbackResponseService:

   • Decisão: Manter as lógicas de negócio para a criação/gerenciamento de solicitações e para o processo de resposta em microserviços distintos.
   • Justificativa: Alinhamento com os Bounded Contexts do DDD (Solicitação de Feedback e Resposta de Feedback). Permite desenvolvimento, deploy e escalabilidade independentes para cada contexto.
   • Implicações: Necessidade de comunicação inter-serviços (e.g., FeedbackResponseService pode precisar consultar FeedbackRequestService para obter detalhes do formulário ou para notificar sobre uma resposta finalizada). Essa comunicação deve ser projetada para ser resiliente.

Padrões Arquiteturais Aplicados

• Domain-Driven Design (DDD):
  • Agregados: SolicitacaoFeedback (englobando Perguntas, Avaliadores Convidados, status, hashId) e RespostaFeedback (englobando as respostas individuais às perguntas de uma solicitação por um avaliador).
  • Serviços de Domínio: Lógica de aprovação/rejeição, geração de código de acesso, validação de prazo, orquestração de notificações.
  • Bounded Contexts: Claramente delineados para FeedbackRequest e FeedbackResponse, cada um com seu microserviço.
• API Gateway: Ponto único de entrada para o frontend, lidando com roteamento, autenticação inicial e agregação leve, se necessário.
• Microservices: Decomposição da aplicação em serviços menores, coesos e independentes.
• Arquitetura em Camadas (dentro de cada microserviço):
  • Apresentação (Controllers): Endpoints REST.
  • Aplicação (Services): Orquestração dos casos de uso.
  • Domínio (Entities, Value Objects, Domain Services): Regras de negócio e estado.
  • Infraestrutura (Repositories, Email Clients): Persistência, comunicação externa.

Considerações de Segurança

• Proteção de Endpoints de Resposta e Autenticação do Avaliador:
  • Acesso aos formulários de resposta apenas via link com hash único.
  • Autenticação de dois fatores implícita para o avaliador (e-mail + código de acesso enviado ao e-mail).
  • Códigos de acesso devem ser de uso único e ter tempo de expiração curto.
• Validação de Dados de Entrada:
  • Validação rigorosa de todos os dados recebidos via API (e.g., formato de e-mail, número de perguntas/avaliadores, conteúdo das respostas).
  • Impedir e-mails de domínio @ciandt.com.br para avaliadores externos.
• Autorização nos Fluxos de Solicitação e Aprovação:
  • Colaboradores só podem gerenciar (criar, editar, excluir) suas próprias solicitações.
  • PDMs só podem analisar e aprovar/rejeitar solicitações de colaboradores sob sua gestão.
  • O UserService será consultado para verificar papéis e hierarquias.
• Anonimato da Resposta: Conforme especificado nos épicos, o sistema deve garantir que, embora o colaborador indique os avaliadores, as respostas individuais não sejam diretamente atribuíveis a um avaliador específico na visualização do colaborador (a menos que o modelo de visualização permita). O processo de resposta em si é autenticado para garantir que apenas o avaliador convidado responda.
• Proteção contra Abuso: Considerar rate limiting para envio de códigos de acesso e submissão de formulários para mitigar riscos de abuso.