Quero comentar com vocês um pouco da minha experiência com arquitetura de software. Será que precisamos disso mesmo? Na empresa onde trabalho não existe uma figura responsável pela arquitetura de software. Geralmente, o desenvolvedor é quem tem que fazer as duas coisas.

Nas várias empresas onde já trabalhei, em uma havia uma pessoa focada na arquitetura dos projetos de software construídos para clientes. Você deve estar se perguntando: será que é necessário ter uma pessoa específica para esse trabalho?

Em alguns casos, dependendo do tamanho do projeto, a empresa pode ter, sim, uma pessoa focada para a construção e a verificação da arquitetura do projeto. Uma situação pela qual passei aqui no meu trabalho esses dias foi uma experiência muito interessante. Se o software não fosse preparado e organizado, o trabalho teria sido muito maior.

Há um projeto importante na empresa e é usado por várias pessoas no Brasil, mais ou menos 60 mil pessoas. Esse projeto possui mais de 1 milhão de imagens armazenadas no servidor e mais de 4 milhões de dados no banco de dados SQL Server 2008.

Existem várias pontas no projeto: a parte web, a parte de serviço no cliente e a parte do serviço no servidor da empresa. Todas essas pontas são vulneráveis e suscetíveis a erro. No caso de erro, alguma coisa pode não ser processada e a informação não é gravada no banco de dados. Seria legal se tivesse uma arquitetura de erro, onde tudo que acontecesse fosse gravado, não acha?

Outros sistemas utilizam informações do nosso sistema, tudo comunicado através de WebService. Comunicação padronizada e aceita por qualquer plataforma ou linguagem de programação.

Com o volume aumentando a cada dia, precisávamos migrar as imagens de um servidor para outro com mais espaço e consequentemente mais rápido. As imagens podem ser copiadas para o outro servidor em um final de semana. Agendamos essa cópia com o pessoal do suporte e tudo ocorreu bem. Na segunda-feira pela manhã, as imagens estavam no outro servidor. Alguns dados físicos no cliente, como imagens, são transmitidas via FTP seguro.

Se a arquitetura do sistema não tivesse bem montada, teria que sair atualizando todos os programas em todas as máquinas do Brasil. Isso porque o FTP seguro mudaria para outro servidor. Sem contar com usuário, senha e endereço físico.

Hoje em dia, para construir um software é muito fácil. Mas construir um software com qualidade e prevendo todos os tipos de projetos, mudanças e migrações já fica mais difícil. Principalmente quando se trata de aplicativos que estão em clientes e em várias partes do mundo.

Outro fato interessante quando se monta a arquitetura é saber o que está acontecendo em cada cliente. Por exemplo, se algum erro acontece no site ou em clientes, esse erro precisa se gravado em algum local para saber o que está ocorrendo. Se o cliente utiliza serviço instalado na máquina, seria interessante fazer com que o serviço mandasse sempre uma notificação falando que está funcionando. Caso parasse de mandar, é porque deixou de comunicar, está sem Internet ou está parado mesmo.

Ainda existem softwares instalados em clientes como VB, Windows Forms, Delphi ou Windows Services. Esses softwares podem utilizar ClickOnce para atualização, mas o serviço, depois de instalado, é necessário parar para poder atualizar, desinstalar e instalar novamente.

Outro ponto importante que precisa ser tratado aqui são as APIs e os frameworks construídos pela empresa. Um arquiteto de software precisa desenvolver frameworks prontos para acessar o banco de dados ou várias bases de dados por exemplo. Existem várias ferramentas prontas que fazem isso, mas será que a empresa onde trabalha não precisa de uma com a string de conexão criptografada? Talvez tenha uma particularidade que a API não tenha.

São necessárias as construções de APIs e frameworks nas empresas, principalmente porque existem validações e trabalhos específicos que podem ser usados por mais de uma solução de software. Um framework pronto agiliza a entrega do software, reutilizando classes e métodos já construídos e testados.

Segue a imagem 1 mostrando a ideia:

Imagem 1 – Quadro arquitetural

Para criar um framework, ou mesmo uma arquitetura para o sistema, é necessário entender o que é preciso ou o que será usado; é necessário criar métodos genéricos e de fácil agregação; é necessário fazer as ligações ou tratamentos para qualquer software utilizar e chamar.

Voltando ao que passei na empresa onde trabalho, no final da migração, o suporte descobriu que precisaria mexer no firewall da empresa devido ao FTP. Depois de tudo migrado, imagens copiadas e banco de dados alterado, o pessoal do suporte falou que teria que mexer no firewall da empresa no final de semana antes da migração. Isso quer dizer que tudo feito até agora precisaria voltar ao que estava antes.

Como o sistema foi feito com certa padronização e usando arquitetura de software, mudamos em um local e pronto, tudo estava de volta funcionando. No nosso caso, toda configuração estava no banco de dados. Configuração, como FTP, usuário, senha para acesso, endereço da imagem e endereço de arquivos. Tudo configurado no banco de dados.

Antes de fazer qualquer coisa, o serviço, site e desktop verifica o endereço gravado no banco de dados antes de gravar a imagem ou arquivo. Para fazer a migração, basta mudar os valores no banco de dados e pronto.

No seu caso, você pode gravar toda essa configuração no arquivo de configuração do aplicativo, sem qualquer problema. Lembrando que é bom que os dados estejam criptografados, para que, caso haja uma invasão, os dados estejam protegidos.

Geralmente, utilizo na minha solução vários tipos de projetos, separo-os em classes de dados, negócio e layout. Isso é bom porque a classe de negócios e dados estão separadas e desconectadas da parte de layout. Como temos vários tipos de layout hoje em dia, como layout para aparelho móvel, TV e outros, basta fazer o layout e acoplar os frameworks.

Padrão de comunicação

O padrão de comunicação entre sistemas é um assunto importante. Tão importante que precisa de uma arquitetura preparada. Como já sabemos, o padrão hoje é XML para comunicação entre sistemas – algumas empresas ainda utilizam o antigo TXT, mas qualquer mudança de layout do arquivo o software de leitura pode para de funcionar.

Enquanto o XML pode ser lido por qualquer linguagem e qualquer plataforma, com o TXT você precisa sair contando posição de string. Se o leitor não utilizar aquela nova TAG, basta ignorar sem mudar qualquer linha de código.

O XML é utilizado em grande parte do layout para aparelhos móveis. Por exemplo, existe o sistema web que consulta o banco de dados e tem a sua própria regra de negócio. Ao criar o mesmo aplicativo para aparelho móvel, basta gerar WebServices que retornam dados usando XML e o aplicativo móvel lê os dados do XML; isto é, os dados são os mesmos existentes do sistema web, porém são disponibilizados no aparelho móvel.

Com XML, existem vários leitores, como o JSON, que facilita a leitura. A base de tudo é o XML que retorna os dados do banco de dados. Para exemplificar o que estou falando, seja a imagem 2:

Imagem 2 – Arquitetura usando WebService XML.

Note que a parte em XML está fora do acesso interno, isso porque a empresa pode escolher que o site seja acessado internamente, como intranet por exemplo.

No resumo geral e para responder a pergunta: é necessário, sim, criar uma arquitetura de software antes mesmo de criar o aplicativo. Dentro da parte de camadas, você pode ter quantas quiser. Lembro apenas que quanto mais camada para o software passar, mais lento o seu sistema pode ficar.

Antes de criar um projeto, pense na arquitetura e nos frameworks a serem feitos de forma genérica. Isso vai te ajudar na criação dos próximos projetos com menos tempo de desenvolvimento. Isso sem contar a organização de todo o projeto…

Bom, espero que tenham gostado e qualquer dúvida podem entrar em contato.