É comum ouvir alguém perguntar qual “arquitetura” usar para uma certa aplicação, ou se usar o Spring junto com o JSF e Hibernate é uma boa escolha, ou como acessar store procedures pelo hibernate. Esta escolha de frameworks é chamada de “escolha da arquitetura”, e diferentes pacotes de escolhas são referidos como “arquiteturas”. Por isso, ouve-se falar que a “arquitetura com Spring é melhor que com EJB”.

Obviamente, por consequência, a pessoa que decide que pacote usar é chamado de arquiteto.

Pode ser chocante, então, para estas pessoas, saber que essas coisas não são arquiteturas e que nada disso tem a ver com arquitetura, mas sim com design.

Infelizmente na língua portuguesa a palavra “design” não tem uma boa tradução. O mais semelhante seria desenho, mas em português isso se confunde com desenho – forma de escrita (que em inglês é draw). Design Patterns é traduzido para Padrões de Projeto porque Padrões de Desenho não pareceu apelar às massas. Então, a bem da exatidão ,vou utilizar a palavra design e não traduzi-la, tal como se faz em artes gráficas.

Se escolher este tipo de frameworks e tecnologia não é arquitetura, então o que é?  Ao fazer isto a pessoa está implicitamente escolhendo a sua plataforma de aplicação. A Plataforma de Aplicação é um conjunto de classes, baseados na Plataforma Virtual, que mediam entre as classes próprias da aplicação e as classes próprias das tecnologias utlizadas na arquitetura. Por exemplo, se a arquitetura decide que um sistema web é que vamos fazer isso implica – em java – utilizar um web container e programar tecnologias baseadas na Servlet API. Mas a Servlet API pura não é muito produtiva. Então escolhe-se, ou faz-se, um conjunto de classes que isolam/encapsulam o uso desta API, de forma que a programação seja de mais alto nível que a utilização direta de uma API base. Nesta situação pode não existir muita vantagem – à primeira vista – mas estamos, implicitamente, escolhendo a nossa Plataforma de Aplicação.

Lamentavelmente, é raro que alguém pense e escolha a Plataforma de Aplicação de forma consciente e explícita. E é aqui que nascem os problemas.

O paradigma de OO é suposto levar à reutilização. A reutilização mais importante é a reutilização de objetos do domínio porque são eles que contêm as regras da aplicação. O resto dos objetos apenas existem para que esta reutilização seja possível isolando toda e qualquer dependência entre as classes do domínio e as classes da tecnologia subjacente.

Por conta deste isolamento não existir na maioria esmagadora das aplicações é que não vemos aplicações serem migradas de web para swing distribuído ou vice-versa. Não há migração, há re-escrita.

Uma Plataforma de Aplicação bem desenhada pode salvar a sua empresa de re-escrever e retestar o mesmo produto infinitas vezes. E como seria uma plataforma de aplicação bem desenhada? Dizer que basta seguir os princípios de orientação a objetos é verdade, mas parece pouco.

É mais fácil entender que os objetos que você quer reutilizar não podem depender de objetos da tecnologia subjacente. A forma de fazer isso é criar um conjunto de interfaces que mediam a comunicação entre o domínio e a tecnologia subjacente. Um exemplo clássico é manipular o objeto HttpServletRequest directamente. Ora isto, por si só, cria uma dependência com a Servlets API, impossibilitando que essa classe seja utilizada fora de um web container. Isto é ruim para a evolução do seu sistema, mas começa sendo um empecilho para o teste automático das suas classes e da sua aplicação. Utilizar uma interface que esconde o objeto HttpServletRequest é a solução ideal. Se estivermos dentro de um servlet container o HttpServletRequest será encapsulado nessa interface agnóstica e se tivermos fora uma outra implementação da mesma interface será passada.

A ideia é isolar todas as classes da tecnologia subjacente. Com isto você já pode começar a pensar em mudar da Servlet API pura para a JSF, por exemplo. Se apenas uma interface não é abstração suficiente, continue abstraindo até que as duas tecnologias possam ser tratadas da mesma forma.

Ter uma Plataforma de Aplicação que pode evoluir sozinha e em separado da aplicação é essencial para a evolução e longividade da aplicação. Se você quer que sua aplicação sobreviva mais do que três anos você precisa disto. Repare que o custo de manter uma plataforma de aplicação atualizada e afinada pode até ser o mesmo re-escrever a aplicação toda a vez, mas o esforço é muito, muito, menor. Um exemplo simples disto pode ser entendido imaginando um sistema clássico de cadastro  pela web ( um micro ERP por exemplo). Em muitos locais é preciso utilizar um campo de data. Você usa um objeto input do HTML e algum javascript para criar uma máscara. Agora alguém pede para internacionalizar essa data para que ela possa ser colocada conforme a localização do usuário e além disso quer colocar um calendário drop down. Ok, você vai em todas as páginas que tem input de data e altera scripts e HTML, página a página, campo a campo, para o novo formato e lógica. Simples, certo? Simples, mas extremanente chato, tedioso, propenso a erros e completamente fora do conceito de componentização e reaproveitamento. Outro cenário, seria você ter definido uma tag costumizada para insersão de data. No primeiro tempo, ela simplesmente renderiza um objeto input do HTML. No segundo, ela renderiza o input e controla o drop down do calendário, a internacionalização, e até a validação. Quantas páginas você alterou? Nenhuma. O esforço é muitíssimo menor. Por quê? Porque você criou um isolamento  entre a necessidade da aplicação (colocar um campo data) e a tecnologia usada para isso (renderizar um campo data com drop down de calendário). Se agora alguém pedir para renderizar usando três combobox de escolha de dia, mês e ano, o esfoço será linear com a vantagem de manter a estratégia anterior. Na primeira opção seria quadrático e sem essa opção.

Criar e manter uma Plataforma de Aplicação não é simples e pode consumir os recursos do seu projeto.  Mas por outro lado, uma Plataforma de Aplicação bem desenhada pode ser reaproveitada para outros projetos diluindo os custos de a manter e aumentando a sua eficácia. Para empresas que produzem software como negócio core, manter esta plataforma não é apenas bom, é essencial. É o maior asset da empresa. Nele estão contidos conhecimentos das várias pessoas que passaram pela empresa, as decisões feitas contra adversidades encontradas na realidade em dezenas de projetos. Nela está a competividade da empresa no mercado face à sua concorrência. E a longo prazo ela reduz custos de manutenção e evolução.

Imagine aplicações criada em java 1.4 que não utilizam os beneficios de algo simples como a classe Executor e em vez disso têm uma implementação in-house. Não é dificil aceitar que essa implementação seja incompleta e cheia de más decisões de design e até de programação. Contudo, se essa implementação foi colocada atrás de uma interface, é muito fácil plugar uma implementação que use Executor quando a aplicação está rodando numa JVM mais recente. E hoje, isso é uma realidade porque java 1.4 não têm suporte oficial há anos. Contudo, muita gente ainda usa porque a sua Plataforma de Aplicação não está preparada para evoluir com baixo esforço. Ela está ultrapassada pelo estado-da-arte.

Se você é dono ou responsável por uma software house, ou por um produto de software que visa estar no mercado por muitos anos e competir com a concorrência você precisa de uma Plataforma de Aplicação. Se você é desenvolvedor, você precisa entender o que é uma Plataforma de Aplicação e como construir uma. Escolher os frameworks certos é apenas o primeiro passo…

Se você acha que já sabe criar uma Plataforma de Aplicação, pense se ela é capaz de se adaptar e tirar proveito das novas classes adicionadas a cada versão do java, de novos frameworks e de novas tecnologias e tendencias. Pense no estado da sua arte. Por exemplo, qual o esforço para incluir ajax na sua aplicação? E para incluir componentes avançados como cheked lists, tabs, animações, mensagens, quantidades e data localizadas conforme o usuário … Como o seu estado de arte vai aproveitar as inovações do Java 7 ? Como ele vai lidar com a descontinuação do Java 5 ? E mais importante que tudo: quanto isso lhe vai custar ?