O livro “Arquitetura Evolucionária. Suporte para mudança contínua "

É hora de relembrar os postulados que permaneceram inalterados ao longo dos anos. Um mundo em mudança dinâmica determina suas próprias regras, inclusive na arquitetura de computadores. As mudanças que estão ocorrendo exigem novas abordagens, forçando os sistemas rígidos a se tornarem flexíveis e se adaptarem às novas condições. O planejamento de longo prazo é possível se tudo estiver mudando constantemente? Como evitar a deterioração gradual da solução arquitetônica ao longo do tempo? Aqui você encontrará respostas e recomendações que protegerão as características mais importantes do projeto no contexto de mudanças contínuas. “Este livro marca um marco importante no entendimento atual do problema. À medida que as pessoas tomam conhecimento do papel do software no século 21, as informações sobre como responder às mudanças, mantendo o que foi alcançado, se tornam uma habilidade essencial no desenvolvimento de software. ” - Martin Fowler

Arquitetura Evolutiva: Armadilhas e Antipadrões

Passamos muito tempo discutindo os níveis adequados de conectividade na arquitetura. No entanto, também vivemos no mundo real e observamos muitas interconexões que prejudicam a capacidade do projeto de evoluir.

Duas práticas de design ruins que são aparentes em projetos de software foram identificadas: armadilhas e antipadrões. Muitos desenvolvedores usam a palavra antipadrão como gíria “ruim”, mas seu significado real precisa ser esclarecido. O software antipadrão consiste em duas partes. Primeira parte: o antipadrão é uma prática que inicialmente parece uma boa ideia, mas que se transforma em um erro. Segunda parte: para a maioria dos antipadrões, existem muitas alternativas muito melhores. Os desenvolvedores de arquitetura percebem muitos antipadrões apenas em retrospecto, por isso é difícil evitá-los. A armadilha à primeira vista parece uma boa idéia, mas imediatamente se manifesta como um mau caminho. Neste capítulo, examinamos armadilhas e antipadrões juntos.

Arquitetura técnica

Esta seção foca na prática comum usada na indústria, o que é particularmente prejudicial à capacidade da equipe de evoluir a arquitetura.

Antipadrão: Rei Vendedor

Algumas grandes empresas adquirem o software Enterprise Resource Planning (ERP) para resolver tarefas comuns de negócios, como contabilidade, gerenciamento de estoque e outras operações de rotina. Isso funciona se as empresas estiverem prontas para dobrar seus processos de negócios e outras soluções para adaptar essa ferramenta e pode ser usado estrategicamente quando os desenvolvedores de arquitetura entenderem as limitações e vantagens.

No entanto, muitas organizações se tornam excessivamente ambiciosas com relação ao software desta categoria, o que leva ao antipadrão do rei do fornecedor, cuja arquitetura é inteiramente baseada nos produtos do fornecedor, o que patologicamente liga a organização a essa ferramenta. As empresas que compram softwares de fornecedores planejam aumentar o pacote com seus plug-ins, a fim de expandir a funcionalidade básica para alinhá-lo à área de assunto da empresa. No entanto, por um longo tempo, a ferramenta ERP não pode ser configurada o suficiente para implementar totalmente o necessário, e os desenvolvedores se sentem impotentes como resultado das limitações da ferramenta e porque a tornaram o centro do universo arquitetônico. Em outras palavras, os desenvolvedores de arquitetura tornaram o rei da arquitetura o fornecedor, ditando decisões futuras.

Para evitar o antipadrão, deve-se considerar o software simplesmente como outro ponto de integração, mesmo que inicialmente tivesse uma ampla gama de responsabilidades. Assumindo a integração no estágio inicial, é mais fácil mudar características inúteis com outros pontos de integração, derrubando o rei do trono.

Ao colocar uma ferramenta ou plataforma externa no centro da arquitetura, os desenvolvedores limitaram significativamente sua capacidade de evoluir em duas direções principais, a saber, tecnicamente e do ponto de vista do processo de negócios. Os desenvolvedores são tecnicamente limitados pela escolha do fornecedor em relação aos sistemas de armazenamento, infraestrutura suportada e muitas outras restrições. Do ponto de vista da área de assunto, uma grande ferramenta de encapsulamento sofre com o antipadrão "Trap nos últimos 10%". Do ponto de vista do processo de negócios, essa ferramenta não suporta o fluxo de trabalho ideal; este é um efeito colateral ou armadilha nos últimos 10%. A maioria das empresas é encerrada enviando para a plataforma, substituindo processos, em vez de tentar personalizar a ferramenta. Quanto mais empresas fazem isso, menos recursos distintos existem entre as empresas, o que é ótimo porque a diferença não é uma vantagem.

O princípio, vamos parar de trabalhar e chamá-lo de sucesso é um daqueles que os desenvolvedores geralmente consideram ao lidar com pacotes de ERP no mundo real. Como eles exigem investimentos significativos em tempo e dinheiro, as empresas relutam em concordar com elas quando não trabalham. Nenhum departamento técnico deseja aceitar a perda de milhões de dólares e o fornecedor da ferramenta não deseja aceitar uma implementação ruim de várias camadas. Assim, cada uma das partes concorda em interromper o trabalho e chamá-lo de sucesso com a maioria das funcionalidades prometidas não cumpridas.

Não associe sua arquitetura ao rei fornecedor.

Em vez de ser vítima do antipadrão do rei fornecedor, considere olhar os produtos do fornecedor como outro ponto de integração. Os desenvolvimentos podem isolar alterações na ferramenta do fornecedor do impacto de sua arquitetura, criando camadas de resistência à destruição entre pontos de integração.

Armadilha: abstração holey

Todas as abstrações não triviais estão, em certa medida, cheias de buracos.
- Joel Spolsky

O software moderno repousa sobre uma torre de abstrações: sistemas operacionais, plataformas, dependências, etc. Como desenvolvedores, construímos abstrações de tal maneira que não temos a capacidade de pensar constantemente nos níveis mais baixos. Se os desenvolvedores precisarem converter os números binários que vêm dos discos rígidos no texto do programa, eles nunca poderão fazer nada! Um dos triunfos do software moderno é o quão bem podemos construir abstrações eficazes.

Mas abstrações são caras, porque não existem abstrações perfeitas e, se fossem, não seriam abstrações, mas algo real. De acordo com Joel Spolsky, todas as abstrações não triviais têm um buraco (vazamento). Esse é um problema para os desenvolvedores, porque acreditamos que as abstrações são sempre precisas, mas geralmente são maravilhosamente colapsadas.

A crescente complexidade das pilhas de tecnologia transformou recentemente a abstração em um problema devastador. Na fig. 7.1 apresenta uma pilha tecnológica típica que remonta a cerca de 2005.

Nesta pilha, o nome do fornecedor nos blocos muda dependendo das condições locais. Com o tempo, à medida que o software se torna mais especializado, nossa pilha de tecnologias se torna mais complexa, como mostra a Figura 2. 7.2


Como pode ser visto na fig. 7.2, cada parte do ecossistema de software se expandiu e se tornou mais complexa. À medida que os problemas enfrentados pelos desenvolvedores se tornam cada vez mais complexos, o mesmo ocorre com suas soluções.

A abstração holey inicial , onde a abstração destrutiva de baixo nível leva ao caos inesperado, é um dos efeitos colaterais do aumento da complexidade da pilha de tecnologia. E se uma das abstrações no nível mais baixo falhar, por exemplo, algum efeito colateral inesperado de uma chamada de banco de dados aparentemente inofensiva? Como existem tantas camadas, essa falha será movida para o topo desta pilha, possivelmente causando "metástases" em seu caminho, manifestando-se em uma mensagem de erro profundamente incorporada na interface do usuário. Depuração e análise retrospectiva tornam-se mais difíceis quanto mais complexa a pilha tecnológica.

Tente entender completamente pelo menos um nível de abstração abaixo do nível em que você normalmente trabalha.
- Software Sages

Embora entender a camada abaixo seja um bom conselho, está se tornando cada vez mais difícil conforme o software se especializa e se torna mais complexo.

Aumentar a complexidade da pilha tecnológica é um exemplo de um problema de equilíbrio dinâmico. Não apenas o ecossistema muda, mas suas partes constituintes se tornam mais complexas e confusas ao longo do tempo. O mecanismo proposto para proteger as mudanças em evolução, ou seja, o uso de funções de condicionamento físico, pode proteger os pontos frágeis das conexões da arquitetura. Os arquitetos definem invariantes nos principais pontos de integração, como funções de adequação, que funcionam como parte do pipeline de implantação, garantindo que a abstração não comece a fluir de maneira indesejável.

»Mais informações sobre o livro podem ser encontradas no site do editor

Para habrozhitelami 20% de desconto no cupom - Arquitetura evolutiva