O protótipo mostrou a tarefa. Agora olhe a qualidade.
Até aqui validamos se a pessoa consegue usar. Agora precisamos pensar em como essa função deve se comportar no sistema real.
“Tem que ser rápido e seguro” parece bom, mas ainda não ajuda
Imagine que alguém diga: “a consulta precisa ser rápida.” Rápida quanto? Em qual situação? Com quantas pessoas usando?
Ou: “o sistema precisa ser seguro.” Seguro contra o quê? Quem pode ver qual informação?
Essas características são chamadas de Requisitos Não Funcionais, ou RNFs. Eles descrevem qualidades e condições de funcionamento.
Vamos partir de situações reais da Conecta
Desempenho
O atendente não pode ficar esperando tanto tempo a ponto de atrasar o atendimento.
Segurança
Um técnico não deve ter acesso a funções administrativas só porque conseguiu entrar no sistema.
Privacidade
A consulta do cliente não precisa mostrar dados internos que não ajudam Ana a acompanhar o notebook.
Acessibilidade
A interface precisa continuar compreensível para pessoas com diferentes formas de interação.
Confiabilidade
Uma falha temporária não pode deixar a ordem numa situação incoerente.
Auditoria
Em ações importantes, precisamos conseguir descobrir quem fez, quando e o que mudou.
Perceba como os nomes técnicos aparecem depois das situações.
Quem é você? E o que você pode fazer?
Essas são duas perguntas diferentes.
Autenticação
“Quem é você?” É confirmar a identidade da pessoa.
Autorização
“O que você pode fazer?” É definir o que aquela pessoa tem permissão para acessar.
O Técnico pode entrar no sistema e registrar diagnóstico, mas isso não significa que ele deva administrar usuários ou acessar tudo.
Precisamos mesmo mostrar todos os dados?
Se Ana quer saber a situação do notebook, não faz sentido exibir CPF completo, endereço e observações internas só porque esses dados existem.
Aliás, CPF significa Cadastro de Pessoas Físicas.
Privacidade começa com uma pergunta simples: “este dado é realmente necessário para esta tarefa?”
Agora imagine que queremos avisar Ana automaticamente
O notebook ficou pronto. A Conecta quer mandar uma mensagem para Ana. Só que o envio será feito por outro serviço.
A partir daqui, o nosso sistema precisa conversar com outro sistema.
Antes de pensar em tecnologia, precisamos saber: o que enviamos? o que recebemos de volta? o que acontece se o outro serviço não responder?
API: o nome dessa “porta de conversa”
API vem de Application Programming Interface, em português Interface de Programação de Aplicações.
A ideia básica é simples: uma API define como um sistema pede ou envia informações para outro.
No nosso caso
A Conecta envia telefone e mensagem. O serviço externo responde algo como “enviado” ou “erro”. Isso já é uma conversa entre sistemas.
E se o serviço de mensagens estiver fora do ar?
O notebook não deixa de estar pronto só porque a mensagem não foi enviada. A situação da Ordem continua correta; apenas o aviso falhou.
Esse raciocínio é mais importante do que decorar nomes de integração.
Alguns nomes que podem aparecer depois
REST
Um estilo muito comum para organizar APIs na Web. O nome completo é Representational State Transfer. Por enquanto, basta reconhecer que é uma forma comum de estruturar essa conversa.
JSON
JavaScript Object Notation. É um formato de texto muito usado para representar dados trocados entre sistemas.
Webhook
É quando outro serviço avisa nosso sistema que algo aconteceu, em vez de esperarmos consultando o tempo todo.
Timeout
Tempo limite de espera por uma resposta.
Retry
Nova tentativa depois de uma falha que pode ser temporária.
Idempotência
Evita que uma mesma operação repetida gere efeitos duplicados indevidos.
Idempotência parece difícil até vermos o problema
Imagine que uma confirmação de pagamento chegue duas vezes. O sistema não pode registrar dois pagamentos iguais só porque recebeu a mesma mensagem de novo.
É para evitar situações desse tipo que esse conceito existe.
Síncrono ou assíncrono?
Síncrono
Precisamos da resposta agora para continuar.
Assíncrono
Podemos registrar ou disparar algo e seguir, sem ficar parado esperando.
Enviar a notificação de “equipamento pronto” pode ser tratado separadamente do estado principal da Ordem. Isso ajuda a evitar que uma falha externa pare o processo inteiro.
Faça agora
- Pegue a consulta da ordem e escreva duas perguntas sobre qualidade que realmente importam.
- Explique a diferença entre autenticação e autorização usando Atendente e Técnico.
- Diga quais dados Ana realmente precisa ver na consulta.
- Conte com suas palavras como a Conecta conversa com um serviço de mensagens.
- Explique o que deve acontecer se esse serviço falhar.
- Escolha uma ação importante e diga que informação de auditoria deveria ficar registrada.
Qualidade e conversa com outros sistemas
Registre as qualidades que realmente precisam ser garantidas e os riscos que aparecem quando a Conecta depende de serviços externos.
Checkpoint — Você consegue começar pelo risco real?
Antes de usar palavras como API, autenticação ou idempotência, você consegue explicar qual problema concreto estamos tentando evitar?