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: [tweet]Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividades de design são sobre arquitetura.[/tweet] Há muitas decisões de design, menos relevantes, que são postergadas e delegadas para que sejam tomadas, potencialmente, com menos rigor.

[tweet]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.[/tweet] 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.