Nesta página
Propriedade de arquitetura
O COADF P-7 é publicado na íntegra. Sistemas de classificação, bases terminológicas e serviços externos de validação vivem em módulos adaptadores, marcados como tais, fora do modelo de dados central. Um serviço externo pode elevar a confiança de um atributo; nenhum deles pode bloquear uma saída. Quando um serviço está indisponível, o sistema produz evidência menos confiante em vez de nada; quando uma licença muda, o núcleo fica intacto; e o conteúdo licenciado é marcado em seus metadados e mantido apartado do núcleo aberto.
Como uma resposta externa altera a confiança não é publicado pelo COADF e não é descrito aqui. Os exemplos registram uma resposta externa e seu status, e não fazem mais nada com ela.
Por que importa
Normas e vocabulários sobrevivem a produtos, mudam de versão no próprio ritmo, trazem termos de licença e são servidos por sistemas que não estão sob a operação de quem os usa. Cada um desses pontos é uma forma de a decisão de outra pessoa virar uma indisponibilidade ou uma reescrita do próprio sistema. O mapa regulatório do COADF nomeia ECLASS e o IEC Common Data Dictionary como vocabulários licenciados tratados dessa forma; o mesmo raciocínio vale para um resolvedor de identificadores, um provedor de classificação ou um serviço externo de validação com disponibilidade própria.
O domínio precisa das respostas deles. Não pode precisar delas para funcionar, e não pode começar a pensar nos termos deles.
Estratégias de implementação válidas
- Porta e adaptador. O domínio define a interface de que precisa, com suas próprias palavras; cada sistema externo recebe um adaptador que a implementa.
- Camada anticorrupção. O adaptador traduz o modelo externo para o modelo do domínio e de volta, de modo que os conceitos e nomes externos param na borda.
- Identificadores próprios. O domínio mantém sua própria identidade para um conceito e armazena um código externo como referência atribuída: o esquema de codificação, a versão do esquema, o código, de onde veio, quando, e se é licenciado.
- Versão fixada. Um código só significa algo dentro de uma versão do seu esquema. A versão é registrada em cada referência armazenada e enviada em cada consulta. Um novo transporte ou uma nova representação do fornecedor pode ficar dentro do adaptador; uma nova versão semântica da norma pode mudar o que os códigos significam, e então o mapeamento do domínio precisa mudar junto.
- Ausência explícita. Um serviço indisponível resulta num “não disponível” registrado, nunca num valor padrão e nunca numa pipeline parada. Toda chamada tem um timeout, e o caminho crítico não espera por um enriquecimento sem o qual consegue viver.
- Conteúdo licenciado marcado. Todo valor armazenado que veio de uma fonte licenciada carrega um marcador, para que exportações, logs, caches e artefatos públicos possam deixá-lo de fora mecanicamente.
- Uma fronteira de plugins onde os adaptadores são opcionais ou fornecidos por terceiros: carregados por meio de um registro do qual o domínio não depende.
Em Python a porta pode ser um typing.Protocol, verificado por verificadores de tipos estáticos; uma checagem isinstance em tempo de execução contra ele precisa de @runtime_checkable e verifica apenas que os métodos existem, não suas assinaturas. O teste de contrato é o que verifica o comportamento.
Modos de falha
Toda falha chamada de indisponibilidade
Um timeout, uma credencial revogada, uma requisição malformada e uma resposta num formato novo, todos informados como “indisponível”. A indisponibilidade se resolve sozinha; a integração quebrada é tentada de novo para sempre e nunca corrigida. É preciso manter separados pelo menos não encontrado, indisponibilidade transitória e integração rejeitada, nos termos do próprio adaptador, não nos códigos de status do provedor.
Classes externas vazam pelo domínio
Os tipos do fornecedor aparecem nas assinaturas do domínio, depois no esquema do banco de dados, depois na API pública.
O SDK do fornecedor vira o modelo de domínio
Classes geradas são usadas como entidades porque já estavam ali, e o modelo do fornecedor passa, sem alarde, a ser o do próprio sistema.
Uma mudança de licença ou de API significa reescrever a lógica de domínio
Os termos mudam, o fornecedor aposenta uma versão ou surge um provedor melhor, e a mudança toca todos os módulos em vez de um adaptador.
Uma indisponibilidade remota bloqueia processamento não relacionado
Uma chamada síncrona sem timeout fica no caminho crítico, e um incidente do fornecedor vira incidente do próprio sistema.
Identificadores externos ganham significado interno por acidente
Regras de negócio se ramificam a partir de um código externo; a versão seguinte do esquema reutiliza ou divide o código, e uma regra que ninguém tocou muda de comportamento.
Conteúdo licenciado escapa
Para fixtures, logs, mensagens de erro, caches, documentação pública ou o texto enviado a um modelo.
Os testes dependem do serviço real
A suíte só passa quando o fornecedor está no ar, então a disponibilidade do fornecedor vira a disponibilidade do build.
Verificação
Teste unitário
Passa quando: O domínio funciona contra um dublê de teste da porta.
Prova de dentes: Trocar o dublê por um que lança o erro “indisponível” do adaptador: o domínio ainda produz seu registro, marcado como não enriquecido.
Teste de arquitetura
Passa quando: Os pacotes do domínio não importam nenhum pacote do fornecedor nem nenhum módulo adaptador.
Prova de dentes: Plantar a importação do fornecedor num módulo de domínio: a regra falha.
Teste de contrato
Passa quando: O adaptador real e o dublê de teste passam nos mesmos testes de contrato da porta.
Teste de integração
Passa quando: Timeouts e erros de conexão do cliente real viram o erro próprio do domínio, e nunca uma exceção genérica que para a pipeline.
Teste de integração
Passa quando: Uma nova representação do fornecedor muda apenas o adaptador, e deixa intactos a API e os testes do domínio. Uma nova versão do esquema muda os dados de mapeamento, e os testes que fixam as regras do domínio dizem se alguma regra dependia de um código que mudou de lugar.
Evidência manual
Passa quando: Uma revisão de licença de cada adaptador: o que pode ser armazenado, por quanto tempo e onde pode aparecer.
Realizações alternativas
- Uma linguagem publicada ou modelo canônico compartilhado por vários contextos delimitados, com cada esquema externo mapeado sobre ele uma única vez.
- Um serviço envoltório em torno de um fornecedor, para que todo consumidor encontre a mesma interface estável.
- Uma cópia espelhada de um vocabulário, onde a licença permite, para que as consultas deixem de depender da disponibilidade.
- Código gerado em tempo de build a partir de um esquema, mantido dentro do pacote do adaptador e nunca exportado dele.
Limitações
- O isolamento não resolve os termos de licença. Ele os torna aplicáveis num só lugar.
- O mapeamento perde nuance. Uma tabela de mapeamento é conhecimento de domínio e precisa de revisão própria.
- O padrão não descreve como a evidência externa afeta a confiança, o que pertence ao P-2.
Fontes
- Python Software Foundation: typing.Protocol and runtime_checkable · documentação da linguagem · Python 3.14 · Verificado em 2026-09-11
