Pode ser considerada a:
Análise e discussão sobre design dos componentes, responsabilidades e relacionamentos de uma aplicação e da estratégia que vai governar a evolução desses componentes com o objetivo de atender aos objetivos, atributos de qualidade e restrições de alto nível do negócio pensando em melhorar a produtividade em desenvolver, manter, atualizar, entregar(deploy) e operacionalizar software.
Uma boa arquitetura de software busca orientar e propiciar formas mais produtivas (mais desempenho e menor empenho) para que possamos no final do dia fazer entregas mais ajustadas às expectativas do negócio com esforço reduzido.
Arquitetura de Software é sempre sobre design. Design nem sempre é arquitetura.
Em outras palavras, todas as decisões que você toma em arquitetura de software envolve design mas o contrário não.
Design Arquitetural por Elemar Jr
Design Arquitetural são as decisões que terão impacto direto e inquestionável no atendimento aos objetivos de negócio, no respeito às restrições e no atingimento aos atributos de qualidade.Por exemplo, decidir se vou ter cache ou não na aplicação é uma decisão arquitetural pois impacta na qualidade, segurança e outros pontos importantes a serem avaliados.
Já o nome de uma classe dificilmente terá relevância arquitetural, é uma decisão importante de design mas geralmente não contém tamanha importância.
Os dois pontos principais são objetivo e escopo.
Aplicado no projeto como um todo, ou seja, a aplicação inteira segue o padrão.
Exemplos de padrões arquiteturais: Padrão Hexagonal ou Padrão de Camadas.
Enquanto isso, um design pattern - ou padrão de código - é focado em resolver um problema específico, são soluções generalistas para problemas recorrentes durante o desenvolvimento de um software. Não se trata de um framework ou um código pronto, mas de uma definição de alto nível de como um problema comum pode ser solucionado (Opus Software).
Autor Desconhecido
Quando você escolhe uma arquitetura adequada para seu projeto, você já está usando uma solução que é resultado de anos de frustração e problemas enfrentados até maturar uma arquitetura que atendesse bem esse universo.
Não existe resposta simples para dizer como será a arquitetura do seu próximo projeto.
Basicamente você tem princípios importantes a serem seguidos - como desacoplamento - e o restante se resume em ir atrás de arquiteturas relacionadas ao que você precisa, em outras palavras, é preciso desenvolver, estudar e descobrir a melhor solução.
Elemar Jr.
Arquitetura é a arte de resolver treadoffs. Se você não sabe do que você está abrindo mão ao tomar uma decisão é provável que você não tem fundamentação boa para tomar essa decisão.
Leonardo Leitão
O quão fácil é testar o que estou criando? Esta pergunta pode ser um parâmetro para avaliar uma boa arquitetura.
Baseado no que estudei, não tenho resposta pra isso e acredito que esse seja um dos tópicos mais polêmicos dentre todos deste post. Cada projeto tem um contexto, cada empresa tem sua cultura e cada pessoa que desenvolve tem suas preferências.
Abaixo deixo uma citação que achei interessante. Ela foi retirada do vídeo Arquitetura de Software: Como funciona a Gupy do canal no Youtube da BrazilJS.
Robson Ventura, na época CTO da Gupy
Até este ponto, algo que na minha opinião não pode ser ignorado ao pensar em arquitetura de projeto é o contexto da empresa.Usando poucas palavras para exemplificar, se você está em uma startup com equipe reduzida e pouco prazo, precisando lançar um produto para mostrar valor aos stakeholders e testar o modelo de negócio, taca-lhe-pau, use o que a equipe domina, não se martirize pensando em exceções e evoluções futuras, neste cenário é bem provável que você reconstrua o software em breve.
Na outra ponta, se você está numa empresa com processos estabelecidos, modelo e regras de negócio claras, todo um ecossistema para interagir, sabendo que outras equipes usarão sua aplicação, é hora de estabelecer um período de estudo (seja uma sprint ou mais), se empenhar e entender que uma semana a mais dedicada para encontrar respostas para questionamentos é um investimento.
Porque um software bem estruturado torna fácil o trabalho de adaptação ao fazer mudanças incrementais e gerar valor. E o que é esse valor?
Lembrando que cada software de uma maneira geral terá uma demanda diferente ditada pelos atributos de qualidade.