Olá pessoal!

Neste post vou falar sobre mais um tópico bastante interessante do livro Software Architecture in Practice – Second Edition, já citado em um post anterior. Desta vez o tema é “o que faz uma boa arquitetura”. Segundo o livro, diferentes arquitetos em diferentes organizações projetam diferentes arquiteturas, de forma que seja complicado definir qual é a mais correta. A ideia geral do tópico é que a arquitetura mais apropriada é aquela que melhor atende aos propósitos definidos para o sistema, sendo que não há uma fórmula única. Diferentes tipos de arquiteturas atendem a diferentes tipos de demandas. Uma arquitetura distribuída, baseada em estrutura client-server pode ser adequada para uma companhia de grande porte do setor financeiro, porém, a mesma solução pode ser completamente inapropriada para uma aplicação voltada à aviação, ou a um compilador, ou ainda a um jogo de vídeo game. E como não há uma fórmula, o tópico estabelece algumas “regras de ouro”, que podem ser usadas em todos os tipos de demandas. As recomendações são classificadas em relacionadas ao processo e ao produto (ou estrutural). Vejamos a seguir:

Recomendações relacionadas ao processo

• A arquitetura deve ser produto de apenas um arquiteto ou de um grupo pequeno, com um líder identificado. Acredito que esta dica esteja relacionada ao anti-pattern Design by Committee, em que a opinião de muitas pessoas é levada em consideração, atendendo seus egos ao invés das reais necessidades, resultando em uma arquitetura pouco eficiente.
• O arquiteto ou time de arquitetos deve ter uma lista de requisitos funcionais, bem como uma lista priorizada do que é definido como atributos de qualidade (devo falar mais sobre este assunto em um próximo post), que são, por exemplo, escalabilidade, performance, segurança, facilidade de manutenção, etc.
• Uma arquitetura deve ser bem documentada, de forma que ao menos uma visão estática e uma dinâmica sejam produzidas. Uma visão estática pode ser um diagrama de componentes ou de implantação da UML. Já a dinâmica pode ser obtida com os diagramas de sequência ou comunicação, por exemplo, também da UML.
• Uma vez documentada, a arquitetura deve ser bem conhecida por todos os stakeholders (clientes / áreas de negócios solicitantes, analistas, desenvolvedores, líderes de projetos, gerentes de projetos, etc.), que por sua vez devem se envolver ativamente na sua revisão.
• Uma arquitetura deve ser analisada através da medição de atributos quantitativos (por exemplo, throughput máximo) e avaliada formalmente quanto aos atributos de qualidade que deve atender, antes que seja tarde para que alterações sejam feitas.
• Uma arquitetura deve ter como resultado um sistema “esqueleto” (estrutura inicial em camadas, serviços, projetos, soluções, etc.) em que caminhos de comunicação sejam testados com funcionalidades mínimas. Uma vez estabelecida, esta estrutura pode ser usada para o crescimento incremental do sistema.
• Uma arquitetura também deve ter como resultado documentações de soluções para áreas de contenção específicas, como por exemplo, utilização de rede, processador, etc.

Recomendações relacionadas ao produto / estrutura

• Uma arquitetura deve ter como característica a definição de módulos cujas responsabilidades funcionais devem ser alocadas de acordo com os conceitos information hiding e separation of concerns.
• Cada módulo deve ter interfaces bem definidas, que encapsulem ou escondam aspectos sujeitos a mudanças. Estas interfaces devem permitir que times de desenvolvimento trabalhem de forma independente entre si (achei este item redundante com relação ao anterior, mas deixei para ficar aderente ao livro).
• Arquitetos devem se preocupar e devem buscar o atendimento de atributos de qualidade. É comum que arquitetos se preocupem apenas com os requisitos funcionais, deixando questões importantes aparecerem apenas quando o sistema entra em produção. Existem táticas específicas para atender requisitos de qualidade. Também falarei sobre este assunto em detalhes em próximos posts.
• Uma arquitetura nunca deve depender de versões específicas de produtos comerciais. Se a integração com produtos comerciais for necessária, deve-se projetar a arquitetura para que mudanças futuras para um produto diferente ou para uma nova versão sejam feitas de forma trivial e pouco custosa (camadas de indireção podem ser usadas neste sentido).
• Módulos que consomem dados devem ser separados de módulos que produzem dados, visando prover maior facilidade de manutenção, uma vez que as mudanças normalmente ocorrem ou no lado consumidor ou no lado fornecedor do dado.
• Para sistemas com processamento paralelo, a arquitetura deve prover processos ou tarefas bem definidas que não necessariamente espelham a decomposição estrutural dos módulos.
• Ainda com relação a processamento paralelo, cada processo ou tarefa deve ser escrito de forma que a atribuição para um processador específico seja facilmente alterada, preferencialmente em tempo de execução.
• A arquitetura deve dispor de um número pequeno de padrões de interação. Ou seja, em geral, o sistema deve fazer as mesmas coisas da mesma forma, provendo maior facilidade de entendimento e leitura do código, melhorando e facilitando modificações futuras.

A maioria destas recomendações são seguidas de forma intuitiva, ou mesmo são embasadas por diferentes estudos ou experiências que levam a estas conclusões. É interessante ter esta consolidação de boas práticas para utilizá-las como um guia a ser lembrado em cada novo projeto de arquitetura. Nos próximos posts devo falar mais sobre assuntos específicos tratados de forma incipiente neste. Até lá.