Um dos princípios do nosso próximo livro Arquitetura como Código é a capacidade dos arquitetos de projetar verificações de governança automatizadas para questões arquitetônicas importantes, criando ciclos rápidos de suggestions quando as coisas dão errado. Essa ideia não é nova – Neal e seus co-autores Rebecca Parsons e Patrick Kua defenderam essa ideia em 2017, na primeira edição de Construindo Arquiteturas Evolucionáriase muitos de nossos clientes adotaram essas práticas com grande sucesso. No entanto, os nossos objectivos mais ambiciosos foram largamente frustrados por um problema comum nas arquitecturas modernas: fragilidade. Felizmente, o advento do Mannequin Context Protocol (MCP) e da IA de agência resolveram amplamente esse problema para os arquitetos corporativos.
Funções de condicionamento físico
Construindo Arquiteturas Evolucionárias outline o conceito de função de adequação arquitetônica: qualquer mecanismo que forneça uma verificação objetiva de integridade para características arquitetônicas. Os arquitetos podem pensar nas funções de aptidão como testes de unidade, mas por questões arquitetônicas.
Embora muitas funções de health sejam executadas como testes unitários para testar a estrutura (usando ferramentas como ArchUnit, NetArchTest, PyTestArch, arco-ire assim por diante), os arquitetos podem escrever funções de aptidão para validar todos os tipos de verificações importantes… como tarefas normalmente reservadas para bancos de dados relacionais.
Funções de condicionamento físico e integridade referencial
Considere a arquitetura ilustrada na Figura 1.
Na Figura 1, a equipe decidiu dividir os dados em dois bancos de dados para melhor escalabilidade e disponibilidade. Contudo, a desvantagem comum dessa abordagem reside no fato de que a equipe não pode mais confiar no banco de dados para impor a integridade referencial. Nesta situação, cada bilhete deve ter um correspondente cliente para modelar esse fluxo de trabalho corretamente.
Embora muitas equipes pareçam pensar que a integridade referencial só é possível dentro de um banco de dados relacional, separamos a atividade de governança (integridade de dados) da implementação (o banco de dados relacional) e percebemos que podemos criar nossa própria verificação usando uma função de adequação arquitetônica, conforme mostrado na Figura 2.
Na Figura 2, o arquiteto criou uma pequena função de health que monitora a fila entre cliente e bilhete. Quando a profundidade da fila cai para zero (o que significa que o sistema não está processando nenhuma mensagem), a função de aptidão cria um conjunto de chaves do cliente do cliente serviço e um conjunto de chaves estrangeiras do cliente do bilhete serviço e afirma que todas as chaves estrangeiras do ticket estão contidas no conjunto de chaves do cliente.
Por que não consultar os bancos de dados diretamente da função de health? Abstraí-los como conjuntos permite flexibilidade – consultar bancos de dados de forma constante introduz sobrecarga que pode ter efeitos colaterais negativos. Abstraindo a verificação da função de aptidão do mecânica de como os dados são armazenados em uma estrutura de dados abstrata tem pelo menos algumas vantagens. Primeiro, o uso de conjuntos permite que os arquitetos armazenem em cache dados não voláteis (como chaves de clientes), evitando consultas constantes ao banco de dados. Existem muitas soluções para caches write-through no raro caso de adicionarmos um cliente. Segundo, o uso de conjuntos de chaves nos abstrai dos itens de dados reais. Os engenheiros de dados preferem chaves sintéticas a usar dados de domínio; o mesmo se aplica aos arquitetos. Embora o esquema do banco de dados possa mudar com o tempo, a equipe sempre precisará do relacionamento entre clientes e ingressosque esta função de aptidão valida de forma abstrata.
Quem executa esse código? Como este problema é típico em arquiteturas distribuídas como microsserviços, o native comum para executar este código de governança é dentro da malha de serviço da arquitetura de microsserviços. Malha de serviço é um padrão geral para lidar com questões operacionais em microsserviços, como registro, monitoramento, nomenclatura, descoberta de serviço e outras questões que não sejam de domínio. Em ecossistemas de microsserviços maduros, a malha de serviço também atua como um malha de governançaaplicando funções de health e outras regras em tempo de execução.
Essa é uma maneira comum de os arquitetos no nível do aplicativo validarem a integridade dos dados, e implementamos esses tipos de funções de adequação em centenas de projetos. No entanto, o especificidade A maioria dos detalhes de implementação dificulta a expansão do escopo desses tipos de funções de aptidão para o nível do arquiteto corporativo porque incluem muitos detalhes de implementação sobre como o projeto funciona.
Fragilidade para metadomínios
Uma das principais lições do design orientado a domínio foi a ideia de manter os detalhes de implementação tão estritamente quanto possível, usando camadas anticorrupção para evitar que os pontos de integração entendam muitos detalhes. Os arquitetos adotaram essa filosofia em arquiteturas como microsserviços.
No entanto, vemos o mesmo problema aqui ao nível meta, onde os arquitectos empresariais gostariam de controlar amplamente preocupações como a integridade dos dados, mas são dificultados pela distância e especificidade dos requisitos de governação. Distância refere-se ao escopo da atividade. Embora os arquitetos de aplicativos e integração tenham um escopo de responsabilidade restrito, os arquitetos corporativos, por natureza, ocupam o nível empresarial. Assim, para um arquiteto corporativo impor governança como a integridade referencial, é necessário que ele conheça muitos específico detalhes sobre como a equipe implementou o projeto.
Um de nossos maiores clientes globais desempenha uma função em seu grupo de arquitetura empresarial chamado arquiteto evolucionistacujo trabalho é identificar preocupações de governação world, e temos outros clientes que tentaram implementar este nível de governação holística com os seus arquitetos empresariais. No entanto, a fragilidade frustra esses esforços: assim que a equipe precisa alterar um detalhe de implementação, a função de aptidão é interrompida. Embora muitas vezes consideremos funções de health como “testes unitários para arquitetura”, na realidade, elas quebram com muito menos frequência do que os testes unitários. (Com que frequência as mudanças afetam alguma preocupação arquitetônica elementary em comparação com uma mudança no domínio?) No entanto, ao expor detalhes de implementação fora do projeto aos arquitetos corporativos, essas funções de adequação quebram o suficiente para limitar seu valor.
Tentamos diversas camadas anticorrupção para metapreocupações, mas a IA generativa e o MCP forneceram a melhor solução até o momento.
MCP e Governança Agente
O MCP outline uma camada de integração geral para os agentes consultarem e consumirem recursos dentro de um metascope específico. Por exemplo, as equipes podem configurar um servidor MCP no nível da aplicação ou da arquitetura de integração para expor ferramentas e fontes de dados aos agentes de IA. Isso fornece a camada anticorrupção perfeita para os arquitetos corporativos declararem o intenção de governança sem depender de detalhes de implementação.
Isto permite que as equipes implementem o tipo de governança que os arquitetos empresariais com mentalidade estratégica desejam, mas criem um nível de indireção para os detalhes. Por exemplo, consulte a verificação de integridade referencial atualizada ilustrada na Figura 3.
Na Figura 3, o arquiteto corporativo emite a solicitação geral para validar integridade referencial ao servidor MCP do projeto. Por sua vez, expõe funções de aptidão através de ferramentas (ou fontes de dados, como arquivos de log) para realizar a solicitação.
Ao criar uma camada anticorrupção entre os detalhes do projeto e o arquiteto corporativo, podemos usar o MCP para lidar com os detalhes da implementação para que, quando o projeto evoluir no futuro, não quebra a governança por causa da fragilidadeconforme mostrado na Figura 4.
Na Figura 4, a preocupação do arquiteto corporativo (validar integridade referencial) não mudou, mas os detalhes do projeto mudaram. A equipe adicionou outro serviço para especialistasque trabalham com tickets, o que significa que agora precisamos validar a integridade em três bancos de dados. A equipe altera a ferramenta interna do MCP que implementa a função de adequação e a solicitação do arquiteto corporativo permanece a mesma.
Isso permite que os arquitetos corporativos estabeleçam efetivamente a governança intenção sem mergulhar nos detalhes da implementação, eliminando a fragilidade das funções de health de longo alcance e permitindo uma governança holística muito mais proativa por arquitetos em todos os níveis.
Definindo as Intersecções da Arquitetura
Em Arquitetura como Códigodiscutimos nove interseções diferentes com a arquitetura de software program e outras partes do ecossistema de desenvolvimento de software program (dados representando uma delas), todas expressas como funções de adequação arquitetural (a parte “código” da arquitetura como código). Ao definir a interseção entre arquitetura e arquiteto corporativo, podemos usar MCP e agentes para declarar intenção holisticamente, transferindo os detalhes reais para projetos e ecossistemas individuais. Isso resolve um dos problemas incômodos dos arquitetos corporativos que desejam criar ciclos de suggestions mais automatizados em seus sistemas.
O MCP é quase idealmente adequado para esse propósito, projetado para expor ferramentas, fontes de dados e bibliotecas de prompts a contextos externos fora de um domínio de projeto específico. Isso permite que os arquitetos corporativos definam holisticamente a intenção ampla e deixem que as equipes implementem (e evoluam) suas soluções.
X como código (onde X pode ser uma grande variedade de coisas) normalmente surge quando o ecossistema de desenvolvimento de software program atinge um certo nível de maturidade e automação. As equipes tentaram durante anos fazer com que a infraestrutura como código funcionasse, mas isso não aconteceu até que surgiram ferramentas como o Puppet e o Chef que poderiam permitir esse recurso. O mesmo se aplica a outras iniciativas “como código” (segurança, políticas, and so forth.): o ecossistema precisa de fornecer ferramentas e estruturas que lhe permitam funcionar. Agora, com a combinação de poderosas bibliotecas de funções de health para uma ampla variedade de plataformas e inovações de ecossistema, como MCP e IA de agência, a própria arquitetura tem suporte suficiente para ingressar nas comunidades “como código”.
Saiba mais sobre como a IA está remodelando a arquitetura corporativa no Software program Structure Superstream em 9 de dezembro. Junte-se ao apresentador Neal Ford e a uma lista de especialistas, incluindo Anjali Jain e Philip O’Shaughnessy do Metro Financial institution, Dom Sipowicz da Vercel, Brian Rogers da Intel, Ron Abellera da Microsoft e Lewis Crawford da Equal Specialists para ouvir insights arduamente conquistados sobre a construção de arquiteturas adaptáveis e prontas para IA que apoiam a inovação contínua, garantem governança e segurança e alinham perfeitamente com os objetivos de negócios.
Membros O’Reilly podem se registrar aqui. Não é membro? Inscreva-se para um teste gratuito de 10 dias antes do evento para participar – e explorar todos os outros recursos da O’Reilly.