A prática da Metáfora Sistêmica é uma forma de explicar a arquitetura lógica através de uma analogia familiar tanto aos desenvolvedores quanto aos usuários. Até aí, ótimo! O maior problema é como conseguir uma boa metáfora. Das 190 páginas de “Extreme Programming Explained”, Kent Beck endereça somente duas delas para explicar o que é a Metáfora Sistêmica e deixa uma lacuna real em como atingí-la. Martin Fowler, um adepto não radical de XP, afirma em “Extreme Programming Examined” que, apesar da Metáfora Sistêmica ter funcionado bem para o projeto C3 (descrito no mesmo livro), ele próprio não faz a mínima idéia em como explicar a forma de obtê-la. Ainda na série XP da Addison-Wesley, os autores de “Extreme Programming Examined” declaram que a metáfora “é uma lacuna real no XP e que os XPmistas precisam resolvê-la” (desculpe, traduzimos “XPers” por “XPmistas”).

Com a polêmica carregada pela Metáfora Sistêmica e pelo fato de boa parte dos programadores praticantes de XP afirmarem que constroem software de sucesso mesmo sem tal metáfora, Kent Beck comentou publicamente que cogita a hipótese de remover esta prática da metodologia. No site de Ron Jeffries (outro guru radical do XP), arquitetura e desenho chegam a ser tratados com um certo tom de deboche.

Por ser um dos mais proeminentes métodos de desenvolvimento da atualidade, existem muitas propostas para preencher a lacuna arquitetural do XP. A seguir, citaremos algumas.

• Estórias do Desenvolvedor (Developer stories) é um prática proposta no artigo “Architecture and Design in eXtreme Programming” dos pesquisadores da Aalborg Universitet. O principal objetivo dessas estórias é introduzir um planejamento arquitetural ao XP. É uma abordagem é razoavelmente simples e, ao mesmo tempo, apresenta razoável eficiência no tratamento de requisitos de qualidade.
• Pesquisadores da Universidade de Wellington, na Nova Zelândia e da Univerdade de Carleton, no Canadá, propõem, através de uma abordagem semiótica, técnicas para desenvolver e avaliar a Metáfora Sistêmica. A Semiótica, mesmo parecendo um termo complicado para alguns, é o estudo formal dos sinais. Ao contrário do nome, a proposta desses pesquisadores é bem simples. Contudo não encontramos referências de sua aplicação na indústria.
• O SEI publicou um artigo descrevendo possíveis aplicações de seus métodos arquiteturais em projetos XP. Sem dúvida, o uso dos consagrados métodos do SEI oferece uma forte e excelente abordagem para arquiteturas dos projetos XP. Entretanto o uso intensivo dos métodos conforme descrito no artigo pode desagradar a alguns agilistas. Mas possivelmente vale a adaptação. A tempo: postamos recentemente um pequeno texto comentando sobre a aplicação do QAW em projetos XP e RUP.
• Martin Fowler, apesar de não apresentar nenhuma teoria inédita, no artigo “Is Design Dead?“, aconselha a não ignorar aspectos arquiteturais já conhecidos e, já no início do projeto, começar com uma arquitetura que aparenta ser necessária. E, em seguida, mesmo que pareça uma contradição ao princípio YAGNI, evoluir a arquitetura simplificando-a ou adicionando complexidades na medida da necessidade.
• A Modelagem Ágil, apresentada no livro de Scott Ambler, pode ser utilizada em aderência ao processo do XP e traz alguns poucos (mas bons) conselhos em como desenvolver a metáfora sistêmica de forma a representar uma arquitetura inicial. Vale a pena também consultar a idéia de Arquitetura Inicial Ágil do Ambler.
• David West propõe a Arquitetura Mandala, um método exótico para tratar a questão arquitetural no XP. Programadores místicos devem simpatizar com o nome.

Os valores e a filosofia de Extreme Programming visam de uma forma “extrema” a simplicidade e a acomodação das mudanças. Mudanças são de fato inevitáveis. Mas, mesmo acreditando nos princípios ágeis, devemos admitir que uma reestruturação arquitetural é uma atividade cara e de alto risco. Um esforço de investigação arquitetural um pouco maior que a indicada pelo XP “puro” pode minimizar boa parte dos riscos – não vale a pena ignorar aspectos estruturais já conhecidos no início do projeto. As abordagens indicadas podem ser um bom caminho para preencher a lacuna da arquitetura de software no XP. Resta ainda a questão: basta uma boa metáfora sistêmica para termos uma arquitetura completa?

Para obter mais visões críticas sobre como a arquitetura pode ser desenvolvida em projetos XP, sugerimos as seguintes referências:

• “Software Architecture and eXtreme Programming” de Andrew Wils e Stefan Van Baelen e
• “The eXtreme Programming (XP) Metaphor and Software Architecture” de James Herbsleb, David Root e James Tomayko da CMU.
• “Metaphor, Architecture, and XP” de David West (mesmo que você não seja assim tão místico).
• Entrevista de Kent Beck publicada em 2005 no The Register a respeito da segunda edição de “Extreme Programming Explained”.
• “Agile Architecture: Strategies for Scaling Agile Development” por Scott Ambler.

O padrão “Layers”

O padrão (pattern) “Layers”, reconhecido inicialmente em POSA 1, identifica o contexto no qual um sistema requer decomposição e se endereça a um ou mais dos seguintes problemas, conforme sintetizado por Eeles:

• Complexidade do sistema dificulta sua inteira compreensão.
• Baixa manutenibilidade – uma alteração gera uma série de impactos.
• Elementos menos estáveis não estão isolados.
• Dificuldade em identificar elementos mais reusáveis.
• Construção de um sistema por diversos times com habilidades distintas.

Tal como no conhecido Modelo OSI, o padrão “Layers” sugere um particionamento com diferentes níveis de abstração. Camadas superiores são clientes das camadas inferiores e estas não tem dependências das primeiras.

As principais estratégias para a decomposição em camadas são baseadas em responsabilidadea e reuso. Também é possível a combinação dessas estratégias em outras, como a modelagem de camadas multidimensionais.

Estratégia “Camadas com base em responsabilidades”
A estratégia com base em responsabilidades é possivelmente a mais popular, onde as responsabilidades de um sistema são isoladas umas das outras. Uma abordagem muito comum é a segmentação em camadas de apresentação, negócios e integração. A flexibilidade e manutenibilidade são os conceitos chave para esta estratégia.

Imagine que, para uma aplicação originalmente com interface web, tenha sido identificada a posterior necessidade de acesso por dispositivos móveis. Sem modificar as demais camadas, é possível oferecer uma camada de apresentação com suporte a tais dispositivos. Outra situação possível é a troca da implementação da camada de apresentação (ex: integração com mainframe para SGBD).

Esta estratégia também permite que indivíduos de habilidades distintas atuem em suas respectivas áreas de competência (ex: programadores web e integradores).

Estratégia “Camadas com base no reuso”
Geralmente derivada de uma diretriz de arquitetura corporativa, a estratégia com base no reuso sugere o agrupamento de componentes em camadas conforme o seu grau de utilização.

Um exemplo típico de estratificação por reuso,  citado por Jacobson, é o conjunto das camadas “Base”, “Específica para Negócios” e “Específica para Aplicativos”. No livro Domain Driven Design, Evan também comenta sobre a separação das camadas e usa os termos “User Interface Layer”, “Application Layer”, “Domain Layer” e “Infrastructure Layer”.

A óbvia vantagem nessa estratégia é o avançado grau de reuso de componentes. Permite também, com facilidade, o provimento e a catalogação de serviços especializados.

Estratégia Camadas multidimensionais
Combina as estratégias baseadas em responsabilidade e reuso.

Mitos “modernos” (e ingênuos) sobre camadas arquiteturais
Recentemente temos percebido um agradável movimento a favor da simplicidade das arquiteturas de software. O uso de múltiplas camadas como pouca distinção de utilidade entre elas tem gerado nomes como “arquitetura lasanha” (ressaltamos que arquiteturas são muito mais que estratificação em camadas, isto é um abuso). Simplicidade é ótimo! Mas, com devido respeito a quem cunhou o termo, o que se deve combater são as arquiteturas ritualísticas, obras criadas por indivíduos que, com pouco conhecimento em arquitetura, não exploram adequadamente o problema e que acreditam que arquiteturas de referência encontradas por aí a tudo se aplicam. O próprio contexto do pattern “Layers” define a natureza do problema no qual ele se aplica.

Muitas vezes, pouco se leva em conta as forças que regem a definição de um arquitetura. Por exemplo, suponhamos a necessidade de um software simples de cadastro sem um contexto de reuso e a ser desenvolvimento por apenas um programador. Possivelmente, o “Layers” nessa situação seria um exagero. Usar o padrão (não somente o “Layers”, qualquer um) para sem considerar todas as forças envolvidas e, principalmente, o problema que está sendo endereçado é inútil e prejudicial. Nesse caso, seria mais uma bela solução para um problema que não existe.

Boas referências sobre decomposição em camadas e assuntos correlatos podem ser encontradas em:

1. “Pattern-Oriented Software Architecture Volume 1: A System of Patterns”, Frank Buschmann e outros.
2. “Layering Strategies”, Peter Eeles
3. “Service Layer”, “Domain Model” e “Anemic Domain Model”, Martin Fower
4. “Design Patterns”, GoF
5. “Applied Software Architecture”, Christine Hofmeister, Robert Nord e Dilip Soni
6. “Arquitetura pragmática: camadas”, Ted Neward
7. “Class Type Architecture: A Strategy for Layering Software Applications”, Scott Ambler
8. “Layering Applications”, Scott Stanchfield, JavaDude.com

Para reflexão: “Ritual é o começo do caos”, Philippe Kruchten, em “The Tao of the Software Architect”.