Praticando agilidade na Arquitetura da Aplicação

A Microsoft publicou um guia sobre Com fazer um design usando uma arquitetura ágil sobre padrões e práticas, fornecendo orientações detalhadas para seguir quando se está construindo a arquitetura de uma aplicação, de forma ágil.

O guia recomenda começar com a seguinte entrada:

• Caso de usos e cenários de uso
• Requisitos funcionais
• Requisitos não funcionais (atributos de qualidade como o desempenho, segurança e confiabilidade)
• Requisitos tecnológicos
• Ambiente de deployment
• Restrições

O design deverá produzir a seguinte saída:

• Caso de usos significantes para arquitetura
• Pontos Críticos de Arquitetura
• Arquiteturas Candidatas
• Esboços de Arquitetura

O guia apresenta agilidade recomendando especificamente não fazer a arquitetura em um único passo, mas recomenda fazê-lo em cinco passos iterativos:

• Passo 1 - Identificar o objetivo das Arquiteturas: Objetivos claros ajudam a focar sua arquitetura, e irão ajudá-lo a focar na resolução dos problemas no seu design. Bons objetivos irão ajudá-lo a determinar quando você terminou, e quando está pronto para passar para a próxima fase.
• Passo 2 - Cenários Principais: Use os cenários chave para focar o seu design no que mais interessa e para avaliar as possíveis arquiteturas quando elas estiverem prontas.
• Passo 3 - Visão geral da aplicação: Entender o tipo de aplicação, arquitetura de deployment, estilos de arquitetura e tecnologias a fim de ligar o seu design ao mundo real em que a aplicação será executada.
• Passo 4 - Pontos Críticos: Identificar os pontos críticos com base em atributos de qualidade e do quadro de arquitetura. Estas são áreas onde os erros acontecem com mais freqüência quando desenhando uma aplicação.
• Passo 5 - Possíveis Soluções: Crie uma arquitetura candidata ou um esboço arquitetural e avalie contra seus cenários principais, pontos críticos e restrições de deployment

Passo 1 - Identificar o objetivo das Arquiteturas.

De acordo com J.D. Meier, Principal Program Manager de padrões & práticas da Microsoft, o objetivo deste passo é de identificar “quanto tempo e quanta energia gastar em etapas posteriores, bem como orientar o seu esforço global”. O resultado do passo 1 deve ser:

• Construir um protótipo
• Identificar os principais riscos técnicos
• Testar os caminhos potenciais
• Compartilhar modelos e entendimentos

Passo 2 - Cenários Principais.

Os melhores cenários são identificados através dos seguintes critérios para casos de uso, de acordo com o J.D. Meier:

1. Eles são importantes para o sucesso e aceitação da aplicação.
2. Eles exercitam suficientemente o design para ser útil na avaliação da arquitetura.

Passo 3 - Visão geral da aplicação.

Uma visão geral da aplicação é necessária para introduzir detalhes da vida real e deixar o design mais concreto, e é criado através dos seguintes passos:

• Determine o tipo da sua aplicação. Primeiro, determine qual tipo de aplicação você está construindo. Trata-se de uma aplicação mobile, a um cliente rico, uma aplicação de internet de grande porte, um message bus, uma aplicação web ou alguma combinação?
• Entender suas restrições de deployment. Depois, compreender o ambiente de deployment e determinar o impacto que isso terá na sua arquitetura.
• Identificar importantes estilos arquiteturais. Determine qual estilo arquitetural você utilizará em seu design. Vai construir uma arquitetura orientada a serviço, cliente-servidor, arquitetura em camadas, um message bus, ou alguma combinação?
• Determine as tecnologias relevantes.Finalmente, identifique as escolhas de tecnologias pertinentes baseadas no tipo da sua aplicação e outras restrições e determine quais tecnologias você poderá usar na sua arquitetura.

O guia oferece conselhos para todos os passos mencionados acima, um exemplo representando a opção de escolha dentre os vários estilos arquiteturais:

• Cliente-servidor. Organize o sistema de forma que o cliente faça requisições a partir do servidor.
• Baseado em componentes. Decompor o design da aplicação dentro da reusabilidade de componentes que revela uma interface bem definida.
• Arquitetura em Camadas. Organize o sistema em grupos de funcionalidades similares em forma de camadas separadas.
• Message-bus. Definir um conjunto de formatos conhecidos usados pelos sistemas interligados para que eles não tenham que saber as diferenças entre os atuais destinatários.
• Object-oriented. Um estilo de programação baseado na divisão de tarefas em objetos reutilizáveis que contêm o comportamento e também os dados relevantes do objeto.
• Service-oriented (SOA). Uma aplicação que expõe e consome funcionalidades como um serviço utilizando contratos e mensagens.

Passo 4 - Pontos Críticos.

Nesse passo alguém poderia " identificar os pontos críticos em sua arquitetura de aplicação para entender as áreas onde é mai provável acontecer erros. Os pontos críticos podem ser organizados em torno de atributos de qualidades”. A longa lista de pontos críticos apresentado pelo guia incluem: disponibilidade, interoperabilidade, durabilidade, confiabilidade, segurança, etc.

Passo 5 - Possíveis Soluções.

Depois de identificar os principais pontos críticos, o primeiro rascunho de arquitetura pode ser produzido. Depois disso, alguém deve voltar para o passo 2 para validar as possíveis arquiteturas, e então seguir os passos 3-5 para gerar um novo candidato. O processo é repetido iterativamente melhorando a cada iteração.