O primeiro principio de uma arquitetura evolutiva é o suporte a mudanças incrementais que não "quebram" a aplicação. A arquitetura baseada em microserviços é um bom exemplo deste tipo de arquitetura. É um estilo arquitetural usado por Rebecca Parsons e Neal Ford da Thoughtworks para descrever características e princípios de arquiteturas evolutivas. Ford e Parsons acreditam que os microserviços reúnem os princípios de uma arquitetura evolutiva devido aos fortes princípios de contexto limitado herdados do Domain-Driven Design (DDD). Os consultores atualmente definem arquiteturas evolutivas dessa maneira:
Uma arquitetura evolutiva suporta mudanças contínuas e incrementais como um primeiro princípio por meio de vários aspectos.
As arquiteturas evolutivas compartilham muitas características, incluindo:
- Modularidade e Acoplamento: O suporte a modularidade, frequentemente relacionado à arquitetura técnica, permite separar componentes por meio de fronteiras bem definidas. Este conceito, por sua vez, simplifica a realização de mudanças que não quebram o sistema; isso é um importante benefício para um desenvolvedor, ao realizar suas mudanças em um sistema. Em contrapartida, Neal e Rebecca observam que as arquiteturas "desleixadas" (big ball of mud) perdem essa modularidade e em consequência não suportam evoluções.
- Organizada em torno da capacidade do negócio: A modularidade em nível de domínio é cada vez mais realizada utilizando Domain-Driven Design (DDD). O particionamento em domínios por meio de microserviços é bastante diferente em comparação a uma abordagem SOA, em que o particionamento é estritamente feito em torno de camadas técnicas.
- Experimentação: Essa particularidade é um dos "superpoderes" trazidos pelas arquiteturas evolutivas. Mudanças em uma aplicação tornam-se muito mais simples. Permitem a criação de testes A/B, lançamento de versões "Canary", entre outras possibilidades. Além disso, uma arquitetura de microserviços pode ser projetada para permitir que várias versões, de um mesmo serviço sejam executadas simultaneamente. Esta abordagem facilita a experimentação e recentemente tem permitido o uso do Desenvolvimento Guiado por Hipóteses.
Outra forma de enxergar as arquiteturas evolutivas é por meio de princípios descrevendo as características de qualquer arquitetura ou método para criá-la. Princípios focando em quando decisões arquiteturais devem ser tomadas incluem:
- Funções Fitness: Uma função arquitetural fitness especifica importantes características de um sistema. Exemplos incluem níveis de uptime, throughput, disponibilidade e segurança necessárias. Uma forma de visualizar é por meio de um gráfico radar apresentando todas as funções utilizadas.
- Trazer o que há de pior para o início: Tomar atitudes capazes de antecipar situações que possam ser a causa raiz de problemas frequentes e desta forma, identificar mais cedo e mais rápido suas causas e permitam a sua automação. Atitudes como esta, ajudam a remover situações geradoras de problemas. Além disso, práticas de entrega contínua, como o uso de técnicas de deployment pipelines e migração de banco de dados são exemplos que mostram que o uso de arquiteturas evolutivas podem ser implementadas de forma fácil.
- Decisões de última hora: O momento o qual uma decisão ocorre é uma das maiores diferenças entre arquiteturas tradicionais e evolutivas. Em uma arquitetura tradicional, decisões como por exemplo sobre infraestrutura, tipo de tecnologia a ser utilizada e padrões de comunicação são tomadas o mais cedo possível antes de escrever qualquer linha de código. Em uma arquitetura evolutiva, é aguardado o último momento antes de se tomar uma decisão. Decidir quando este momento ocorre pode ser uma tarefa difícil, mas este é um cenário onde as funções de adequação (fitness) podem fornecer uma orientação a respeito. No entanto, decisões que influenciam de forma importante a arquitetura, ou que podem ter impacto em fatores críticos de sucesso do projeto precisam ser tomadas com antecedência.
Neal Ford e Rebecca Parsons concluem afirmando que uma decisão arquitetural não é uma equação, mas sim uma fotografia do processo em andamento naquele exato momento, enfatizando o quanto é crítica a consciência operacional para a arquitetura evolutiva, referindo-se tanto aos movimentos de entrega contínua como DevOps.
Neal Ford recentemente apresentou um webinar abordando arquiteturas evolutivas. Durante o QCon Londres 2015, Rebecca Parsons fez uma apresentação sobre o mesmo tema.