Adicione módulos a um serviço de rede modular sem quebrar seus limites

## Conecte os módulos por interfaces compartilhadas, não por detalhes internos - Trate o sistema de módulos como o limite central de extensão. Autenticação, armazenamento, validação, transformação, roteamento e endpoints de protocolo devem implementar interfaces compartilhadas do framework, em vez de chamar diretamente os detalhes internos uns dos outros. - Mantenha interfaces estáveis, primitivas de configuração, tratamento de endereços, tipos de erro e contratos de registro em uma camada reutilizável do framework. Coloque as implementações concretas em pacotes internos organizados por função. - Mantenha enxuto o ponto de entrada do executável. Ele deve carregar o pacote do serviço, garantir que os módulos incorporados estejam registrados e chamar a sequência de inicialização. - Conecte os módulos de nível superior por meio da configuração e de um registro com inicialização tardia. Encaminhe cada solicitação ou mensagem por um fluxo explícito de validadores, modificadores e destinos selecionados por regras de correspondência. - Evite dependências circulares fazendo com que as implementações dependam de interfaces estáveis, e não de implementações do mesmo nível. ## Compile com o wrapper de compilação do repositório e rode os testes afetados - Use o wrapper de compilação do repositório como caminho canônico, incluindo as opções de etiquetas de compilação ou de funcionalidades que ele oferece. Não o substitua por um comando de compilador improvisado que omita metadados de versão ou sinalizadores obrigatórios. - Execute o conjunto completo de testes unitários para alterações transversais. Quando o comportamento atravessar limites de protocolo, armazenamento ou entrega, execute o ambiente de testes de integração a partir do diretório de trabalho documentado. - Preserve a injeção de versão realizada pelo sistema de compilação. Se o ambiente de execução usar uma dependência apoiada em código nativo, confirme que o compilador e as bibliotecas nativas necessários estão disponíveis antes de diagnosticar o código-fonte. - Durante as iterações, prefira um teste focado no pacote e, antes de concluir, execute o caminho de integração diretamente afetado. Informe qualquer teste ignorado e o motivo ambiental concreto. ## Adicione um módulo novo na pasta da sua função e registre-o 1. Coloque a implementação no diretório interno correspondente à sua função, como validação, destino, autenticação, armazenamento, consulta, transformação ou tratamento de endpoints. 2. Implemente tanto a interface comum do ciclo de vida dos módulos quanto a interface específica da função. Mantenha os contratos de função na camada estável do framework. 3. Registre a fábrica durante a inicialização do pacote usando a convenção estabelecida de nomes com prefixo de função. 4. Adicione a implementação à conexão dos módulos incorporados do serviço por meio da importação de registro ou do manifesto designado pelo repositório. Quando esse for o padrão estabelecido, o código de registro deve continuar dedicado apenas ao efeito colateral. 5. Comece por um esqueleto ou auxiliar existente para a função, quando houver. Use o auxiliar sem estado somente quando o módulo realmente não mantiver estado mutável entre solicitações. 6. Adicione testes focados em configuração, registro, comportamento bem-sucedido, falhas temporárias e mapeamento de erros nos limites. ## Retorne erros que indiquem se dá para tentar de novo e escondam detalhes internos - Use o pacote de erros estruturados do framework para erros que atravessem limites entre módulos. Não retorne um erro formatado, porém não classificado, quando o chamador precisar do estado do protocolo, do comportamento de nova tentativa ou da atribuição do módulo. - Inclua o código de estado externo, o estado aprimorado ou subtipo quando houver suporte, uma mensagem genérica segura para o cliente e o nome da verificação ou do destino responsável. - Marque explicitamente as falhas transitórias para que os despachantes possam distinguir condições que permitem nova tentativa de rejeições permanentes. - Não inclua configuração do servidor, caminhos internos, credenciais nem detalhes de implementação em mensagens visíveis para o cliente. - Anexe campos de diagnóstico estruturados a falhas internas inesperadas e registre-as por meio do registrador do framework. Preserve a causa original sem expô-la a clientes remotos. ## Não compartilhe estado entre requisições e recupere panics em tarefas em segundo plano - Nunca compartilhe entre solicitações ou mensagens um estado mutável pertencente a uma solicitação. Pressuponha que verificações e transformações sejam executadas concorrentemente, a menos que o contrato do framework as serialize explicitamente. - Toda goroutine ou tarefa em segundo plano iniciada deve recuperar panics em seu limite, registrar a falha e impedir que uma tarefa derrube todo o serviço. - Normalize identificadores externos antes de compará-los ou armazená-los. Para identificadores semelhantes a domínios, aplique a representação Unicode, a forma de normalização e o dobramento Unicode de maiúsculas e minúsculas exigidos pelo framework, em vez de inventar uma limpeza local. - Analise a configuração dos módulos por meio do mapa de configuração compartilhado e do método de ciclo de vida. Rejeite definições desconhecidas ou inválidas de maneira coerente com os módulos existentes. - Use o registrador do framework em vez do registrador global da linguagem. Quando o framework oferecer esse recurso, crie registradores com escopo de operação ou de entrega para que eventos relacionados mantenham o contexto. - Antes de mesclar, verifique por meio de testes o registro, a análise de configuração, a execução concorrente, a normalização, as falhas estruturadas e os registros no limite mais estreito que comprove cada comportamento.