Há uma coisa que eu pensei errado por bastante tempo.
Eu costumava achar que se a policy fosse escrita corretamente, o resultado também seria correto.
Só depois de ler @NewtonProtocol m é que percebi que isso não era suficiente.
A mesma policy.
Basta alterar alguns parâmetros como limite de transações, lista permitida ou o período de validade para que o resultado da execução possa ser completamente diferente.
O interessante é que a lógica não muda.
O que muda é o contexto em que essa lógica é aplicada.
Naquela hora, eu entendi uma coisa.
Em muitos sistemas, o que determina o nível de confiança não é o código.
E sim a configuração.
O código costuma ser auditado.
A configuração raramente é revisada com esse mesmo cuidado.
Enquanto é justamente nela que entram as decisões humanas para dentro do sistema.
A Newton faz algo bem interessante: a cada vez que o PolicyClient altera a configuração, ele gera um novo policyId.
Assim, pelo menos o usuário sabe que o sistema está executando com uma configuração diferente da anterior.
Mas ainda tenho uma pergunta.
E se duas aplicações usarem a mesma policy, mas com configurações totalmente diferentes?
Será que estamos reutilizando o mesmo conjunto de regras.
Ou estamos criando dois sistemas de crença diferentes sob o mesmo nome?
Talvez o futuro das policies não seja apenas tornar a lógica transparente.
Mas também tornar transparentes as suposições que são inseridas antes de a lógica começar a rodar.
#newt $NEWT $M

O que merece mais escrutínio em um sistema de policies?
🔘 The policy logic
100%
🔘 The configuration
0%
2 Votos • Votação encerrada