Arquitetura de Aplicações

Objetivo

O objetivo deste artigo é descrever alguns pontos que devem ser considerados quando se criar uma arquitetura de aplicações. Acredito que para se obter resultados com esse processo, antes de pensar em quais tecnologias e padrões existentes de mercado devem ser adotados é muito importante ponderar os resultados que se espera desse processo.

O termo "arquitetura de aplicações" é um pouco ambíguo no mercado brasileiro de TI (acredito que no mundial também). Geralmente usa-se o termo para o profissional que em grandes organizações detecta sobreposições de funções entre sistemas distintos e propõe projetos de uniformização para esses sistemas (substituir, desenvolver um novo, identificar integrações, procurar alternativas no merdado). O mesmo termo é usado também dentro da disciplina de desenvolvimento de software para um projeto mais técnico e detalhado de como o software deve ser desenvolvido. Nesse artigo, abordaremos o segundo.

Por que definir uma arquietura?

Muitas pessoas devem se fazer essa pergunta, e muitas vezes não fica claro os ganhos que podem ser obtidos definindo uma boa arquitetura.

Em equipes com vários desenvolvedores, não é raro um desenvolvedor simplesmente não conseguir dar manutenção no código do outro. Isso acontece principalmente por causa da ausência de padrões de codificação e uma arquitetura não definida. Um mesmo problema em programação pode ser resolvido de "n" formas diferentes, cada uma com seus prós e contras. As vezes pela dificuldade de entender a solução adotada por um desenvolvedor, o outro acaba refazendo parte do código, ou ainda levando muito mais tempo do que o necessário para realizar uma manutenção.

Exemplo: Imagine uma aplicação Web com um "Wizard" para cadastrar determinada informação. O usuário precisa passar por 5 páginas até chegar no seu objetivo final que é realizar o cadastro. Esse mesmo problema pode ser resolvido de várias formas, dependendo da tecnologia usada (não vamos discutir a "elegância" de cada uma aqui. Apenas para exemplificar):

  • Criar uma única página que mantém estado na página até concluir todo o processo (isso seria possível em ASP.Net). O problema aqui é o "peso" dessa página, pois todas as informações de estado são mantidas na página (ViewState).
  • Criar várias páginas e manter o estado em Session. Aqui podem-se gerar problemas caso exista mais de um web server. Ainda se usar um servidor de estado centralizado, pode-se ter problemas com serialização dos objetos até o servidor de estado.
  • Criar várias páginas sem persistência nenhuma de estado e uma mandar
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License