Arquitetura X Design de Software

Muito provavelmente se você e da área de TI ou já participou de alguma maneira de projeto de sistemas, já deve ter ouvido um desses termos.

Se buscarmos a definição do Google ou da wikipedia, termos a seguinte descricão:

Design de Código é o processo pelo qual um agente desenvolve um código de modo a atender o requisito funcional também fazendo com que este mesmo código seja possível de ser mantido com o mínimo de dificuldade pelo próximo agente.”

A arquitetura de software representa a estrutura ou as estruturas do sistema, que consiste em componentes de software, propriedades externamente visíveis dos componentes e os relacionamentos entre eles. Focar na arquitetura, o mais cedo possível, para reduzir o risco e organizar o desenvolvimento.”

Como esperado, essas definições não explicam absolutamente nada, de forma clara, sendo extremamente genérica e abstrata! (Muitas vezes acho que eles fazem esses texto na plataforma “gerador de lerolero”) – Para quem não conhece: http://lerolero.bgnweb.com.br/leroleroti.html

Pra tentar explicar de maneira simples e objetiva, acho que vale fazer uma analogia com algo mais concreto, do mundo real:

Na construção de uma casa, podemos ter dois profissionais com funções distintas trabalhando juntos para entregar uma bela casa:

  • Arquiteto: Faz a planta da casa, focado no melhor aproveitamento no espaço
  • Designer de interiores: Seleciona os móveis, cores, luzes, materiais e acessórios para compor o ambiente

Arquitetura de software

Em software, o arquiteto de software é a visão de mais alto nível, onde organizamos as pastas, namespaces, pacotes e camadas. Definimos como vamos modelar nosso sistema ( Arquitetura hexagonal, Onion architecture, Frame architecture, etc…). Com a arquitetura de software, definimos a melhor linguagem, sistema operacional, tipo de banco de dados, frameworks e ambientes de computação ( servidor dedicado, compartilhado, containers, acesso local, etc…). Podemos utilizar qualquer tecnologia para compor e integrar a solução arquitetural do projeto, sempre focado nos objetivos:

  • Interoperabilidade
  • Compatibilidade
  • Desempenho
  • Escalabilidade
  • Performance

“Arquitetura de software é o estudo que ajuda a definir como cada um dos componentes vao conversar entre si em uma aplicação”

Alguns exemplos práticos e reais de arquitetura de software:

Arquitetura em camadas (Layered pattern): A arquitetura de software baseada em camadas organiza um sistema de conjunto que pode ser desconstruído em diferentes serviços, trazendo um modelo incremental de desenvolvimento. Os casos mais comuns para o uso desse padrão são em software de e-commerce e desktop.

Arquitetura cliente-servidor (Client-server pattern): Estilo organizado em serviços, combinando dados do cliente e do servidor. Para isso, é primordial que o cliente disponibilize uma rede de acesso às informações. (Este cenário é um dos mais conhecidos na rotina das pessoas, já que costumam ser utilizados em aplicativos bancários e e-mail).

Arquitetura MVC (Model-view-controller pattern): Distribuído em três camadas (Modelo, Visão e Controle), este padrão é um dos mais comuns para o mundo online, uma vez que traz um modelo interativo de sistema.

Arquitetura de microsserviços (Microservices pattern): Por fim, este exemplo de arquitetura de software utiliza múltiplos serviços e componentes para desenvolver uma estrutura modular favorecida.

Hoje, é um dos padrões preferidos dos desenvolvedores e arquitetos de software. Isso porque possibilitam a escalabilidade e independência dos módulos, que até podem utilizar diferentes linguagens e programações.

Além de ser um dos modelos favoritos do momento, o padrão de microsserviços também fica entre os destaques nas tendências para a evolução da arquitetura de software.

Design de Software

Focado mais no “baixo nível”, quando falamos na codificação, independente da linguagem escolhida, o design de software foca mais de como vamos organizar a estrutura do código, qual padrão de design ( design pattern) vamos utilizar para que a longo prazo seja fácil expandir e dar manutenção ao sistema (inclusive novas equipes que seguirem no futuro).

Padrões e “filosofias” como Solid, DDD ( Domain Drive Design), DRY (Dont Repeat Yourself), KISS ( keep it simple Stupid!) são definidas no design.

Não é raro em projetos de software, toda vez que entra uma nova equipe, desenvolver um novo sistema do zero, por dificuldade em manter ou expandir os sistemas existentes.