O mais difícil não é definir a arquitetura de um sistema, mas sim essa arquitetura sobreviver aos desafios do dia a dia. Deadlines, mudanças de escopo, pessoas entrando e saindo do time. Isso tudo pode ferir a arquitetura com o passar do tempo.
A arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reúso do projeto dos componentes e padrões entre projetos.
Além da escolha dos algoritmos e estruturas de dados, a arquitetura envolve: decisões sobre as estruturas que formarão o sistema, controle, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, distribuição física dos elementos escalabilidade e desempenho e outros atributos de qualidade
Arquiteturas de software não são (ou não deveriam ser) sobre frameworks. Arquiteturas não deveriam ser fornecidas por frameworks. Frameworks são ferramentas para serem usadas.
Arquiteturas de software deveriam falar sobre o sistema, não sobre os frameworks usados.
Arquiteturas de software são estruturas que suportam os "use cases" do projeto.
Uma boa arquitetura de software permite decisões como frameworks, bancos de dados, servidores, serem adiadas.
Uma boa arquitetura de software permite que mudanças nestas decisões sejam fáceis de serem tomadas.
Evolutionary Software Architecture
Robert Martin - Clean Achitecture
Introdução a Arquitetura de Software - Taller
Clean Architecture using Golang - Elton Minetto - Medium
Ready for changes with Hexagonal Architecture - Netflix TechBlog
Cloud design patterns - Azure Architecture Center | Microsoft Docs
Modelling software architecture with PlantUML - DEV Community 👩💻👨💻