Bom, gostaria de comentar hoje a 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 tem que fazer as duas coisas.

                Nas várias empresas onde trabalhei, houve uma que tinha 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 isso?

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

                Tem 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 comunicando 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, 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 e mais.

                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 atualizar, desinstalar e instalar novamente.

                Outro ponto importante que precisa ser tratado aqui são as APIs e framework’s construídos pela empresa. Um arquiteto de software precisa desenvolver framework’s prontos para acessar o banco de dados ou várias bases de dados por exemplo. Existem sim 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 específicas, 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 o 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. Isto 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 se houver caso de invasão, os dados estarão protegidos.

                Geralmente utilizo na minha solução vários tipos de projetos, separo 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 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 antes, pense nos frameworks a serem feitos de forma genérica e 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 tenha gostado e qualquer dúvida pode entrar em contato pelo site.

This article was originally written by:

Maurício Júnior
MCP, MCAD, MVP Microsoft
www.mauriciojunior.org
blog.mauriciojunior.org                      
www.ecode10.com