Artigos Delphi Padrões de arquitetura de aplicações corporativas no Delphi
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Contém nota Quickupdate, Conteúdo sobre Engenharia.
Padrões de Arquiteturas de Aplicações Corporativas
Este artigo traz técnicas de arquiteturas de aplicações corporativas, que são úteis para a organização da lógica de negócio. Os princípios e boas práticas mostrados neste artigo trarão grandes resultados no desenvolvimento de aplicações corporativas ricas e complexas e sem contar que auxiliarão o leitor a aplicar essas técnicas na prática, com exemplos do dia a dia utilizando conceitos de orientação a objeto.


Em que situação o tema é útil
Este tema é útil para os desenvolvedores que querem aprimorar o desenvolvimento de sistemas de grande porte utilizando técnicas para organizar a lógica de forma adequada, preparando-a para futuras alterações e também para os desenvolvedores que ainda não tem conhecimento sobre o assunto e querem aprender. Este artigo lhe auxiliará desde o planejamento da regra de negócio quanto na execução de técnicas para organizar as mesmas no projeto. Este artigo é voltado para o desenvolvimento de aplicações ricas e complexas, mas não limitando a elas, podendo ser também utilizada em projetos pequenos e simples.

Uma das maiores causas de enxaqueca nos desenvolvedores está fortemente ligada a uma má arquitetura adotada no início do desenvolvimento de uma aplicação, um caminho adotado, que inicialmente parecia ser o mais fácil se tornou um grande pesadelo. Todo projeto de software deve começar por uma boa arquitetura, pois é essa etapa que guiará todo o ciclo de vida do projeto, se ela for mal projetada, consequentemente o projeto será mau feito. Existe uma série de fatores que deve sempre ser levado em conta ao se iniciar um projeto, uma delas é a verificação e análise da arquitetura adotada, mas infelizmente em muito dos casos não se chegar nem a se projetar antes de desenvolver. Simplesmente tem-se algumas conversas básicas e vão logo com a mão na massa. Esse fator é bastante comum em empresas pequenas, onde se busca um retorno o quanto antes, contudo, sem pensar no futuro. Um pouco de tempo gasto inicialmente no projeto com planejamentos arquitetônicos de software, economizará tanto dinheiro como o tempo gasto para manter o mesmo projeto.

Até quando os desenvolvedores e empresas não vão perceber que a melhor solução dos seus problemas está antes de iniciar o projeto? Será que ainda terão que perder muito dinheiro e tempo para que percebam isso?

Infelizmente a realidade dos desenvolvedores é essa, na verdade podemos dizer que é do ser humano, que só muda de atitudes quando sente no bolso o peso de suas más decisões. Um bom projeto sempre começa com um ótimo planejamento.

O grande pesadelo

Desenvolver software não é difícil, a questão está no fato de que um software pode possuir um ciclo de vida longo, o que existe um desenvolvimento de qualidade, que se adapte às mudanças por esse tempo. É por isso que surgem padrões de projeto e metodologias de processo de software, como a CMMI (Nota DevMan 1), que buscam respectivamente tornar um software mais adaptável e garantir a qualidade do de desenvolvimento.

Nota do DevMan 1

CMMI é o acrônimo de Capability Maturity Model Integration, que possui as melhores práticas necessárias para o desenvolvimento e maturidade do software. Integra práticas definidas pelo modelo CMM, criado em 1980 como um modelo de avaliação de risco para empresa de software pelo Departamento de Defesa dos Estados Unidos.

Você já perguntou o motivo de toda vez que um cliente pede uma alteração em uma funcionalidade os programadores sentem uma tremenda dor de cabeça no momento em que começam a alterá-la? Muitas das vezes o segredo de um sono tranquilo está ligado à forma em que programamos o nosso software, somos a causa dos nossos pesadelos, nós somos culpados dos nossos erros. Vamos entender melhor a solução do nosso problema, ou melhor, a solução para diminuir a nossa dor de cabeça.

Arquitetura

O termo arquitetura abordado desse artigo, nada mais é do que um conjunto de técnicas ou experiências vividas por um grupo de desenvolvedores, que são compartilhadas. Segundo Ralph Johnson “A arquitetura se resume em coisas importantes que se devem fazer e para isso precisam ser tomadas decisões difíceis, caso essas decisões passam a ser mais fáceis do que se propôs, não é arquitetura”. Ou seja, o termo arquitetura empregado nada mais é do que uma tomada de decisão.

O análise arquitetural nada mais é do que o análise dos problemas enfrentados e que demandam uma série de tomadas de decisões, para que possamos projetar uma arquitetura que possa prolongar ou manter o ciclo de vida do projeto em questão.

...

Quer ler esse conteúdo completo? Tenha acesso completo