Arquiteturas Simples Duram Mais

Um amigo outro dia me perguntou que tipo de arquitetura eu usaria num caso bem peculiar. Basicamente ele foi encarregado de definir a arquitetura corporativa de um grande banco, ou seja: definir hoje a forma como aplicações serão construídas pelas próximas décadas. Basicamente ele vai se ro cara que vai ser xingado por algumas centenas de programadores nos próximos tempos, não importa que arquitetura escolha.

Há poucos dias atrás falamos aqui sobre arquiteturas de referência e seu efeito danoso. Geralmente quando alguém tem à frente um desafio desse ele logo pensa em um modelinho que mostra obriga o uso de uma meia dúzia de frameworks e padrões (clássico moderno: Struts/JSF e JPA, clássico vintage: Struts 1.1 e EJB/DAO). Para melhorar ainda é incorporado um conjunto de classes “utilitárias” feitas com práticas que talvez tenham servido para um projetinho piloto mas hoje em dia só atrapalham.

Ainda assim uma arquitetura corporativa é algo interessante. Quando empresas grandes não possuem uma macro-arquitetura acabam crescendo de maneira desordenada e criando dezenas de aplicações redundantes e gambiarras de integração entre sistemas. Note no entanto que uma arquitetura corporativa não é uma arquitetura de referência, a arquitetura corporativa não fala sobre como implementar aplicações mas sim provê guias sobre como integrá-las, define as relações previstas em no ecossistema que é uma grande empresa.

Quais são as melhores macro-arquiteturas que você conhece? Eu consigo pensar em algumas: Apache, UNIX, World Wide Web… Nestes ecossistemas aplicações novas surgem, são alteradas e morrem todos os dias há décadas, um sistema criado com a tecnologia mais recente de 2007 vai rodar tranqüilamente neste ambiente. Por quê?

Porque estas arquiteturas se baseiam em primitivas e contratos, não em especificações rígidas. Criar um módulo para o Apache , um programa para rodar em UNIX ou uma site é basicamente criar um programa de computador em uma das plataformas suportadas que obedeça a um contrato.

Uma boa arquitetura corporativa vai definir algumas políticas e contratos para a aplicação se relacionar com o meio-ambiente e só isso. No caso do banco, poderíamos definir que uma aplicação deve disponibilizar via uma interface POX/REST seus WebServices, que ela deve utilizar a API do Mogile FS para guardar dados em disco, que cache deve ser feito utilizando a API do memcached.

E se o arquiteto quiser sair do padrão? Ótimo, saia, mas ele deve oferecer compatibilidade com o ambiente.

E se eu já tiver comprado um sistema que faz WebServices via SOAP? Eu preciso criar um meio de disponibilizar estes serviços via POX/REST também. Pode ser uma adaptador simples, um ESB, o que quer que seja. É como quando você compra um equipamento eletrônico com tomada americana, você não vai mudar uma tomada na sua casa para o padrão exótico, vai é comprar o adaptador necessário para plugar ele nas tomadas do seu ambiente.

Mas e se não precisarmos de filesystem distribuído? E se já estivermos utilizando uma solução de cache que faz mais sentido nesta aplicação?

Ótimo, use. O uso de filesystem X, cache Y, banco de dados Z deve ser um guia. Toda vez que alguém precisar de uma solução de cache, filesystem, etc. ele olha o guia da empresa, se não servir ele usa algo que sirva. O que importa é que o uso fique encapsulado no sistema. Imagine que ao invés do Oracle 10g eu resolva usar um MySQL na minha aplicação. Está ótimo mas eu devo manter essa peculiaridade interna à minha aplicação. Os outros sistemas que vierem a se comunicar com o meu não devem precisar saber sobre a existência deste banco, eu não posso usar este banco para comunicação entre aplicações (o que já é uma coisa péssima para se fazer de qualquer forma).

O que importa é:

  1. O arquiteto tem liberdade para resolver seu problema da maneira mais adequada
  2. O novo sistema é compatível com o meio-ambiente

Para ser um bom arquiteto não é necessário ter tanta experiência assim, basta saber olhar os casos de sucesso e aproveitar o que funciona. Geralmente as técnicas utilizadas nestas arquiteturas são também catalogadas como Padrões Arquiteturais em livros. Um bom arquiteto tem que ser um ávido leitor de livros e de código.

8 Responses to “Arquiteturas Simples Duram Mais”

  1. Leandro says:

    Parabéns outra vez.

    O trecho abaixo exprime uma idéia que sempre abracei o extermínio das “tabelas corporativas”.

    “Os outros sistemas que vierem a se comunicar com o meu não devem precisar saber sobre a existência deste banco, eu não posso usar este banco para comunicação entre aplicações”

  2. Olá Phillip,

    Quando comecei a leitura e lí o trecho: “Basicamente ele foi encarregado de definir a arquitetura corporativa de um grande banco, ou seja: definir hoje a forma como aplicações serão construídas pelas próximas décadas” eu disse por dentro: “esse post é pra mim”. Estou vivendo essa situação.

    Eu realmente detesto engessar as coisas e sou mais favorável aos guidelines como você mencionou.

    Vai ser um trabalho difícil pois a maioria das pessoas aqui acredita que temos que ter uma coisa engessada para evitar que as “fábricar” (Bah, doi só de falar) não façam besteira. Eu não concordo muito e estou tentando mudar a mentalidade do pessoal.

    Ah e a propósito, talvez você não se lembre do cenário do parque de 17 servidores (acho que foi isso que você me falou) com 2 deles batendo 100% de CPU que eu não tinha muita noção quando você me questionou la na Globo. Eu pesquisei sobre monitoramento da JVM e hoje já estou usando com alguma frequência o jps e jstack (que naquele dia eu nem sabia da existência deles, e foi bom você não ter me falado pois é bom aprender a pesquisar :p). Valeu pelo cenário. Aprendi muito.

    Um abraço e parabéns pelo artigo

  3. anderson says:

    Contrato. Essa questão é complicada. OK, defino uma arquitetura e na forma de interfaces defino as características que o sistema deve seguir.
    Mas..ai..o programador desesperado precisa fazer algo diferente, que sai do contexto da interface(contrato) e altera a interface pra fazer o Gambi Design Pattern dele.
    Se eu estiver errando algum conceito, por favor me corrija, mas é esse o contrato ?

  4. pcalcado says:

    @emerson
    Pois é, mas nem essas ferramentas nós tínhamos :) Foi na base do UNIX top e thread dump

    @anderson
    O contrato fala sobre interação entre os sistemas, basicamente. Se o programador fizer uma gambiarra dentro da aplicação dele isso é um problema do arquiteto da aplicação, não do arquiteto corporativo.

  5. @pcalcado
    Pois é. Eu uso thread dump também no windows com Ctrl+Break.

  6. [...] Arquitetura é para facilitar, e não para atrapalhar. Tambem não gere código. Diminua a quantidade de código. Menos código, menos falhas. [...]

  7. [...]  aí acabou o semestre! colega: Calma…. Daí a gente fez o projeto, com dezenas de camadas,  igual ela ensinou pra gente.  De um módulo que passa pro outro que passa pro outro…. E a [...]

  8. [...]  aí acabou o semestre! colega: Calma…. Daí a gente fez o projeto, com dezenas de camadas,  igual ela ensinou pra gente.  De um módulo que passa pro outro que passa pro outro…. E a [...]