Arquitetura e Design de Software andam lado a lado. Existe uma linha tênue que os separa. Este artigo busca não só conceituar, como também humanizar o assunto. Mostrar as diferenças e refletir sobre haver o certo e o errado.

Arquitetura de Software

Conceituar arquitetura é uma tarefa árdua. Não há um consenso. A definição é subjetiva. Existem diversas definições. Irei utilizar uma definição que é comumente aceita e a qual compartilho.

Arquitetura de software trata dos componentes, suas responsabilidades e como eles se relacionam para atingir os objetivos do negócio. O papel do arquiteto consiste também em definir uma estratégia para tomada de decisões.

A estratégia deve responder: Quais são os princípios ou elementos que o projeto deve obedecer quando o time apresentar duas soluções para o mesmo problema?

Os elementos podem ser:

  • Performance
  • Estabilidade
  • Segurança
  • Economia de recursos
  • Manutenbilidade
  • Escalabilidade
  • Outro. Que estejam alinhado com os objetivos da empresa.

Por que?

A natureza de um projeto de software é melhorar um processo ou criar um novo produto. Em ambos casos, problemas do negócio serão expostos. Cabe a equipe dar soluções.

Dado um problema, eventualmente parte da equipe apresenta um contexto e a proposta A. Outra parte apresenta o contexto e a proposta B.

Levando em consideração os contextos ambas propostas estão certas e resolvem o problema. Diante de tais situações será a estratégia definida que vai nortear entre A ou B.

Os problemas são abstratos. Possuem mais de uma solução viável.

Design de Software

Iowa man sits at a messy table while holding paint covered pencil and brush

Tal como a arquitetura de software, design é um conceito amplo. Dependendo do contexto o termo muda drasticamente. Este artigo toma como base o texto de Jack W. Reeves, What is Software Design?.

Enquanto a arquitetura trata o software no alto nível. Componentes, responsabilidade e relacionamentos. O design trata-os de forma íntima. No nível do código.

O design de software é um exercício no gerenciamento da complexidade. A complexidade vem da organização. Seus processos, envolve pessoas e também outras empresas.

Finalidade do software

A natureza da maioria dos softwares atualmente está ligada a questões sociais. Automatizar processos feito por pessoas.

Veja o exemplo: Preencher a ficha do paciente, levar até a sala do médico e pendurar na cesta da porta.

Preecher, levar e pendurar são comportamentos que podem ser traduzidos em: Uma tela Web para preencher a ficha. Um banco de dados para armazenar e levar os dados até o médico.

Abstrair conhecimentos das pessoas e entender suas tomadas de decisões, é um processo social.

O design de software é um processo criativo. Uma tentativa de organizar e padronizar os problemas através de elementos comuns. Diante deste cenário príncipios do SOLID e os Design Patterns do GOF se materializam. São abordagens bem sucedidas. Que resolvem problemas com caracteristicas em comum.

É difícil avaliar se um design está certo ou errado. Sua natureza é interpretativa. Depende do observador. Por isso a utilização de padrões já amplamente adotado aumenta as chances de sucesso e garante facilidades na manutenção do código.

Conclusão

Arquitetura e design de software são abstrações do mundo real. Traduzidos em software. Sua natureza, quase que sempre, advém de problemas sociais. Automatizar o processo atual feito por pessoas.

Construídos a partir da complexidade do negócio, feito por humanos. Seu entendimento depende do observador. Nem sempre para duas soluções haverá uma obrigatoriamente errada.

Os conceitos apresentados neste post não estão escritos em pedra. É uma definição das inúmeras que podem ser encontradas.

É uma parte da minha visão de mundo. Auxilia na minha jornada. Espero que minha visão, construído a partir de minhas experiências, auxiliem e direcionem vocês.

Referencias