Quais são as diferenças entre Arquitetura e Design de Software?

Há tempos, participamos e acompanhamos discussões acaloradas sobre quais seriam as diferenças entre as práticas de arquitetura e design de software. Consequentemente, sobre o nível de autonomia e liberdade dos membros do times de desenvolvimento para a tomada de decisões envolvendo aspectos estruturantes.

De forma categórica: Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividades de design são sobre arquitetura. Há muitas decisões de design, menos relevantes, que são postergadas e delegadas para que sejam tomadas, potencialmente, com menos rigor.

O objetivo primário da arquitetura de software é garantir que os atributos de qualidade, restrições de alto nível e os objetivos do negócio, sejam atendidos pelo sistema. Assim, compete a aqueles que elaboram a arquitetura tomar as decisões de design necessárias para que esse objetivo seja atingido.

Decisões arquiteturais estabelecem os limites que devem ser observados durante todas as demais atividades de design. Aliás, estas atividades devem sempre produzir artefatos – sobretudo código – em conformidade com esses limites.

Todas as decisões de design que não tenham relação direta com o atendimento de um atributo de qualidade, restrição, ou objetivo do negócio são não-arquitetônicas. Além disso, todas as decisões de design tomadas na implementação de um componente específico que não sejam “visíveis” fora dele – ou seja, que não façam diferença fora dos limites deste componente – também não são, geralmente, arquiteturais.

Muitas decisões de design relacionadas a arquitetura de software não passam, muitas vezes, de descrições abrangentes indicando o que deve ser evitado. Ou seja, as decisões relacionadas a arquitetura nem sempre indicam implicações concretas, apenas restringindo como novos padrões e interfaces, não arquiteturais, devem ser especificados e implementados.

Algumas vezes, definições arquiteturais são tão abstratas como, por exemplo: “Todos os endpoints da API X devem realizar consultas, em execuções concorrentes, utilizando,  primariamente, um cache de dados compartilhado, retornando resultados em não mais do que 40 ms.”

Há cenários, entretanto, onde as decisões de design relacionadas a arquitetura de software podem ser extremamente “detalhadas” – apontando, inclusive, formatos, protocolos e outros padrões de tecnologia. Se as escolhas de estruturas de dados ou de algoritmos forem fundamentais para que uma sistema atenda seus atributos de qualidade, restrições ou necessidades de negócio, então, essas escolhas são arquiteturais.

O nível de detalhamento das decisões arquitetônicas é, desta forma, sensível ao contexto e ao nível de risco tolerado. Quanto maiores os riscos para o atendimento dos atributos de qualidade e dos objetivos do negócio, mais rigorosas, profundas e detalhadas serão as decisões arquiteturais.

Em Resumo
  • O problema

    Debates recorrentes tentam estabelecer, de forma categórica, quais são as diferenças entre as atividades de design e arquitetura de software. Dessa forma, também há muita discussão sobre o nível de autonomia e liberdade de cada um para a tomadas de decisões de design que sejam estruturantes.
  • O fato

    Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividade de design são sobre arquitetura. O objetivo primário da arquitetura de software é garantir que os atributos de qualidade, restrições de alto nível e os objetivos do negócio, sejam atendidos pelo sistema. Qualquer decisão de design que não tenha relação com este objetivo não é arquitetural. Todas as decisões de design para um componente que não sejam "visíveis" fora dele, geralmente, também não são.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *