Template — microserviço¶
Escopo: backend e infraestrutura associada, conforme a governança; consumidores aparecem somente como atores externos.
Modelo editorial. Preencher com evidências e seguir os estados de implementação.
Identificação e evidências¶
Nome lógico e repositório; responsabilidade/owner; linguagem/framework; commit/branch/data; estado (Implementado, Parcialmente implementado, Planejado, Experimental ou Legado). Indicar o ambiente na descrição de deployment; evitar metadados repetidos.
Responsabilidade e fronteira¶
Objetivo, capacidades, ownership e responsabilidades delegadas. Diagrama C4 de componentes do container, com tecnologias e relações nomeadas. Não representar pacote Java como serviço implantado separado.
APIs e consumidores¶
Tabela: método, path público/interno, finalidade, consumidor, autenticação, tenant e fonte. Identificar versões, exceções públicas, formatos de conteúdo, streaming e compatibilidade. Referenciar OpenAPI sem tratá-lo como prova exclusiva do comportamento.
Dependências e comunicação¶
Tabela: destino, contrato/protocolo, finalidade, configuração, timeout/retry, propagação de identidade e teste. Para mensageria: produtor/consumidor, exchange/fila/routing key, ack, correlação, retry/DLQ e deduplicação.
Dados e caches¶
Owner e tecnologias; referências para modelos canônicos quando existirem; escopo tenant/global; caches, TTL e invalidação; transações e limites. Não duplicar catálogos de campos.
Segurança e tenancy¶
Origem da identidade, validação, autorização, claims, resolução/propagação de tenant, tratamento de referências externas e exceções. Distinguir mecanismo implementado de mecanismo aplicado aos endpoints.
Comportamentos relevantes e erros¶
Transformações e composições; status/exceções; política de falha; idempotência, retry e concorrência quando aplicáveis. Não deduzir garantias a partir da presença de uma biblioteca.
Configuração e deployment¶
Separar defaults do código, configuração do ambiente local e experimentos. Documentar variáveis, profiles/overrides, imagem, portas, namespaces, réplicas, probes e recursos pertinentes ao serviço e ao ambiente local, com suas fontes. Charts/Helmfiles comprovam somente o ambiente local. Para infraestrutura e deployments corporativos, encaminhar à documentação oficial do TOTVS Apps, sem duplicar configurações ou listar informações pendentes. Não copiar segredos.
Observabilidade e validação¶
Logs, métricas, tracing/correlação, testes associados e resultados realmente executados. Comandos de build/teste por repositório. Resultado unitário não comprova integração distribuída nem quality gate remoto.
Limites e referências¶
Vincular análises abertas e evidências por classe/método/configuração/teste/commit. Destacar limitações funcionais e riscos relevantes. Incertezas da análise ficam no relatório final da tarefa.