A Fábrica de Políticas de Newton faz com que as políticas pareçam mais infraestrutura do que recursos
Continuo percebendo o mesmo padrão sempre que leio sobre novas aplicações de blockchain. As equipes de desenvolvimento geralmente passam a maior parte do tempo construindo carteiras, painéis, recursos de negociação ou fluxos de automação. A discussão sobre regras de autorização costuma começar muito mais tarde, depois que a aplicação já está ganhando forma. Para mim, isso faz com que o design de políticas pareça algo que foi adicionado a uma aplicação, em vez de algo em torno do qual a aplicação é construída.
Enquanto percorro o fluxo de implantação do Newton, percebo que a ordem muda. Os desenvolvedores não começam conectando uma aplicação a uma política. Eles primeiro criam e registram um NewtonPolicy por meio do NewtonPolicyFactory; somente então um PolicyClient começa a usar essa política. O fluxo de implantação trata silenciosamente a política de autorização como um componente independente antes de a aplicação começar a processar requisições.
Do meu ponto de vista, isso muda o papel do design de políticas. Uma equipe de desenvolvimento deixa de decidir regras de permissão depois de escrever a lógica da aplicação. A equipe passa a decidir qual política de autorização deve existir antes de a aplicação entrar no ar. Essa pequena mudança no fluxo de trabalho incentiva os desenvolvedores a pensar sobre governança enquanto estão projetando a aplicação, em vez de pensar nisso depois que terminam de construí-la.
Eu me vejo comparando esse fluxo de trabalho com a construção de um prédio. Arquitetos não finalizam os escritórios primeiro e depois decidem onde a fundação deve ficar. A fundação é planejada antes de qualquer outra coisa, porque cada andar depende dela. A Newton's Policy Factory me dá a mesma impressão. As funcionalidades da aplicação podem mudar com o tempo, mas a política de autorização é esperada para existir antes que essas funcionalidades comecem a lidar com transações reais.
Também percebo que esse fluxo de trabalho pede que as equipes de desenvolvimento assumam mais responsabilidade no início do projeto. Toda política implantada precisa vir de uma versão de fábrica compatível, então uma atualização de protocolo pode exigir um novo deployment de política mesmo quando a lógica de autorização em si não mudou. O planejamento extra acontece antes da implantação, em vez de virar um problema de manutenção mais tarde.
O que fica comigo não é o contrato da fábrica nem o comando de implantação. Para mim, a ideia mais interessante é que a Newton's Policy Factory incentiva equipes de desenvolvimento a tratarem políticas de autorização como infraestrutura de longo prazo, e não como recursos temporários de aplicação. Às vezes, a maior decisão arquitetural não é a funcionalidade que o aplicativo entrega. É a política que já existe antes mesmo da primeira funcionalidade chegar aos usuários.
Fonte: Documentação do Newton Protocol (Architecture Overview & Smart Contract Integration). Análise pessoal com base no fluxo de implantação documentado.