3.1 Fundamentos de arquitetura

Visão geral e motivação

A arquitetura de software é o conjunto de decisões de design significativas que são caras de mudar: a estrutura dos principais componentes, as relações entre eles e as propriedades que o sistema inteiro deve exibir. Pense nela como o modelo mental compartilhado que permite a muitas pessoas construir um produto coerente. Numa equipe pequena, a arquitetura pode viver em algumas cabeças e evoluir à medida que se avança. Numa grande organização (centenas de engenheiros, dezenas de equipes, vários produtos, anos de roteiro), a arquitetura se torna aquilo que mantém todos coordenados. Quando é clara, as equipes se movem de forma independente sem colidir. Quando é vaga, cada dependência entre equipes vira uma negociação e cada incidente vira um projeto de arqueologia.

Para empresas e governo, os fundamentos importam ainda mais, porque os sistemas são de longa vida, fortemente regulamentados e compartilhados entre departamentos. Um sistema tributário, uma plataforma de benefícios, um prontuário nacional de saúde ou o livro-razão central de um banco sobreviverá às carreiras das pessoas que o construíram. As decisões que você toma hoje sobre acoplamento, propriedade de dados e atributos de qualidade restringem o que é possível por uma década ou mais. Reguladores e auditores esperam cada vez mais uma arquitetura documentada e defensável: evidência de que confiabilidade, segurança, privacidade e acessibilidade foram projetadas desde o início, e não remendadas. Acertar os fundamentos não é questão acadêmica. É a diferença entre uma plataforma que se adapta a novos mandatos e uma que precisa ser reconstruída do zero.

Este capítulo cobre os fundamentos duradouros que sobrevivem à moda tecnológica: atributos de qualidade (os “-ilidades”), requisitos arquiteturalmente significativos, funções de aptidão e arquitetura evolutiva, documentação leve com o C4 e o arc42 e análise estruturada de compromissos. São as ferramentas que permitem a uma grande equipe raciocinar sobre a arquitetura de propósito e não por acaso.

Princípios fundamentais

Arquitetura trata de compromissos, não de respostas certas. Toda decisão significativa troca uma qualidade por outra. O trabalho é fazer essas trocas deliberada e transparentemente.
Os atributos de qualidade são requisitos. Desempenho, disponibilidade, segurança e manutenibilidade devem ser especificados com o mesmo rigor das funcionalidades, ou serão sacrificados sob pressão de prazo.
Nem todo requisito é arquiteturalmente significativo. Concentre a escassa atenção de design nos requisitos que moldam a estrutura, são difíceis de mudar ou carregam alto risco.
A arquitetura precisa poder evoluir. O grande design inicial falha porque o conhecimento é menor no começo. Projete incrementalmente e proteja as propriedades-chave com verificações automatizadas.
Documente decisões, não só diagramas. O raciocínio por trás de uma escolha (e as opções rejeitadas) vale mais que uma figura do resultado.
Torne a arquitetura legível para quem não a criou. Pessoas novas, auditores e futuros mantenedores devem conseguir reconstruir a intenção.
Adie as decisões que puder, tome as que precisar. Mantenha as opções abertas onde a mudança é barata. Comprometa-se cedo apenas onde o compromisso tardio é caro.

Recomendações

Especifique os atributos de qualidade como cenários mensuráveis

Metas vagas como “o sistema deve ser rápido” ou “altamente disponível” não podem ser testadas nem impostas. Em vez disso, escreva cada atributo de qualidade como um cenário concreto, com um estímulo, um contexto e uma resposta mensurável: “Quando os usuários simultâneos de pico chegam a 50.000, 95% das requisições de busca se completam em até 300 ms.” Cubra os atributos que importam ao seu domínio: disponibilidade, desempenho, escalabilidade, segurança, manutenibilidade, observabilidade, acessibilidade, portabilidade e eficiência de custo. Classifique-os em voz alta, porque você não consegue maximizar todos ao mesmo tempo. Um sistema ajustado para a máxima consistência não será também maximamente disponível.

Identifique os requisitos arquiteturalmente significativos (ASRs)

Reserve tempo para separar os ASRs dos requisitos comuns. Um requisito é arquiteturalmente significativo se toca muitos componentes, é caro de satisfazer, impõe uma restrição estrita ou é tecnicamente arriscado. Mandatos regulatórios (residência de dados, retenção, auditabilidade), cenários de alta carga, integração com sistemas legados de registro e fronteiras rígidas de segurança costumam ser ASRs. Mantenha uma lista curta e viva deles e rastreie as principais decisões de design até essa lista, para que os revisores vejam por que a arquitetura tem a forma que tem.

Adote a arquitetura evolutiva e as funções de aptidão

Trate a arquitetura como algo que muda passo a passo em direções guiadas, e não como um projeto fixo. Uma função de aptidão é um teste automatizado e objetivo de que uma característica arquitetural específica está se sustentando: uma verificação em tempo de build de que nenhum módulo importa de uma camada proibida, um teste de desempenho que quebra o pipeline se a latência p99 regride, uma varredura de segurança que bloqueia dependências sabidamente vulneráveis, um teste que confirma que nenhum serviço mantém uma conexão direta com o banco de dados de outro serviço. As funções de aptidão transformam a intenção arquitetural em proteções impostas continuamente: a única forma de manter viva essa intenção numa equipe grande e em mudança.

Documente com C4 e arc42

Use o modelo C4 para descrever a estrutura em quatro níveis de zoom (Contexto do Sistema, Contêineres, Componentes e Código), de modo que cada público leia o nível que lhe convém e nenhum diagrama isolado precise dizer tudo. Use o arc42 como modelo para a narrativa ao redor: objetivos, restrições, contexto, estratégia de solução, blocos de construção, cenários de tempo de execução, implantação, preocupações transversais, decisões e riscos. Registre as decisões individuais como curtos Registros de Decisão de Arquitetura (ADRs): contexto, decisão, status e consequências, um arquivo por decisão, versionado junto ao código. Se você adotar apenas um hábito de documentação, que seja o ADR: compensa mais que qualquer outra coisa para equipes grandes.

Conduza análise estruturada de compromissos e guie o design pelo risco

Para sistemas de alto risco, use um método como o Architecture Tradeoff Analysis Method (ATAM) para pesar arquiteturas candidatas contra cenários priorizados de atributos de qualidade. Ele traz à tona os pontos de sensibilidade (onde uma decisão afeta fortemente um atributo) e os pontos de compromisso (onde afeta vários). Para um toque mais leve, adote o design guiado pelo risco: gaste esforço de design em proporção ao risco. As partes de baixo risco e bem compreendidas precisam de pouca cerimônia. As decisões novas, de alto impacto ou irreversíveis merecem protótipos, investigações e revisão formal.

Compromissos: prós e contras

Abordagem	Prós	Contras
Grande arquitetura inicial	Clareza de coordenação. Menos surpresas tardias em programas de escopo fixo	Decisões tomadas quando o conhecimento é menor. Lenta. Frágil diante da mudança
Arquitetura emergente / evolutiva	Adapta-se ao aprendizado. Menos desperdício. Apoia a entrega rápida	Risco de deriva sem funções de aptidão. Exige forte disciplina de engenharia
Avaliação formal no estilo ATAM	Rigorosa, auditável, expõe conflitos ocultos	Intensiva em tempo e especialização. Exagero para pequenas mudanças
ADRs leves + C4	Barata, legível, incremental, escala para muitas equipes	Só é tão boa quanto a disciplina de mantê-los atuais

A tensão central é entre certeza e adaptabilidade. Programas governamentais de preço fixo e sistemas críticos para a segurança se inclinam para mais rigor inicial e avaliação formal, porque o custo da mudança tardia ou da falha é enorme. As organizações de produto de ritmo acelerado se inclinam para abordagens evolutivas guardadas por automação. A maioria das grandes organizações precisa de ambas: governança mais pesada nas decisões irreversíveis e de alto impacto e nas preocupações transversais, e design mais leve e emergente em todo o resto. Ambos os extremos falham a seu modo: superarquitetar desperdiça anos e não entrega nada, enquanto subarquitetar produz um emaranhado que não escala nem pode ser auditado.

Perguntas para discutir com sua equipe

Quando dois dos seus atributos de qualidade colidem sob carga, qual vence, e vocês escreveram essa ordem de prioridade? Toda arquitetura força trocas: a máxima consistência enfraquece a disponibilidade, a segurança rígida acrescenta latência, o cache agressivo briga com a auditabilidade. Numa equipe grande o perigo é que esquadrões diferentes presumam em silêncio prioridades diferentes, de modo que um otimiza a vazão enquanto outro guarda a consistência estrita, e o conflito só emerge durante um incidente. Em contextos corporativos e governamentais, um regulador perguntará qual atributo vocês protegeram e por quê, então a classificação precisa ser explícita e defensável e não folclore. Leve seus cenários de atributos de qualidade e classifique-os em voz alta uns contra os outros, par a par, até a ordem ficar inequívoca. Depois codifique o vencedor como uma função de aptidão para que a prioridade se sustente sob pressão de prazo em vez de se erodir.
Quais das suas decisões recentes foram portas de mão única, e elas receberam mais escrutínio que as portas de duas vias? O design guiado pelo risco diz para gastar esforço de design em proporção à dificuldade de reverter uma decisão, mas a maioria das equipes revisa toda mudança com aproximadamente a mesma cerimônia. Isso desperdiça atenção em escolhas baratas e reversíveis enquanto as irreversíveis (um modelo de dados gravado num registro legal, um contrato de API público, um armazenamento de dados central) passam com pouco questionamento. Pegue as decisões significativas do último trimestre e classifique-as por reversibilidade, depois pergunte se as irreversíveis receberam protótipos, investigações ou revisão formal. Em sistemas corporativos e governamentais de longa vida, o custo de uma porta de mão única errada se acumula por uma década, então o rigor extra se paga muitas vezes. Ajuste o peso do seu processo à reversibilidade da decisão, não ao tamanho do diff.
Para a sua próxima decisão de alto risco e difícil de reverter, quem precisa estar na sala, e contra quais cenários vocês pontuarão as opções? Uma revisão estruturada de compromissos no estilo ATAM compensa o custo quando uma decisão é irreversível e toca vários atributos de qualidade ao mesmo tempo, e seu poder vem das pessoas presentes: entrega, segurança, operações e os responsáveis por política ou negócio que sentem as consequências. Pule uma dessas vozes e você descobre o conflito depois da construção, do jeito que uma escolha de cache pode quebrar em silêncio um requisito de auditabilidade. Leve os cenários priorizados de atributos de qualidade como a rubrica de pontuação e procure os pontos de sensibilidade, onde uma opção balança com força um único atributo, e os pontos de compromisso, onde move vários. O resultado que você quer é um curto ADR que registre as opções rejeitadas e por quê, para que o raciocínio sobreviva às pessoas que o formaram. Se nenhuma decisão próxima parece justificar isso, isso mesmo vale conferir, porque um grande programa sem decisões irreversíveis no horizonte costuma não estar olhando longe o bastante.
Se uma pessoa nova ou um auditor externo tivesse apenas a sua arquitetura escrita, conseguiria reconstruir por que o sistema tem a forma que tem, e quando vocês testaram isso pela última vez? A arquitetura que vive em algumas cabeças seniores é um ponto único de falha: quando essas pessoas seguem adiante, o raciocínio por trás de toda decisão difícil de reverter vai junto, e a próxima equipe o reaprende por meio de incidentes. Para uma grande organização, a legibilidade da arquitetura (diagramas C4 que correspondem à realidade, uma narrativa arc42, ADRs que registram as opções rejeitadas) é o que permite a dezenas de equipes raciocinar sobre o mesmo sistema sem uma reunião. Leve um ADR recente e um diagrama atual, entregue-os a alguém que não construiu o componente e observe até onde a pessoa chega antes de precisar perguntar a alguém. Em contextos corporativos e governamentais, um auditor fará exatamente esse exercício, e uma documentação que descreve o sistema do ano passado é pior que nenhuma, porque engana as próprias pessoas que precisam certificá-lo. Trate a atualidade do registro escrito como uma propriedade mensurável e ponha uma função de aptidão ou uma cadência de revisão por trás de mantê-lo verdadeiro.
Quais das suas características arquiteturais são protegidas hoje por uma função de aptidão automatizada, e quais ainda dependem de todos se lembrarem da regra? A intenção que vive apenas numa página de wiki ou na memória de um revisor se erode no momento em que chega um prazo, porque a regra de camadas, a fronteira de nenhum banco de dados compartilhado e o orçamento de latência são exatamente o que as equipes cortam sob pressão. Numa base de código grande e que muda depressa, a única intenção que sobrevive é a que um build impõe, então a distância entre as características que vocês afirmam e as que realmente verificam é o seu risco arquitetural real. Liste suas características significativas, marque cada uma como imposta, revisada manualmente ou desprotegida e leve as três últimas vezes em que uma revisão pegou uma deriva que uma função de aptidão poderia ter pegado antes. Em sistemas regulamentados e públicos isso importa em dobro, porque um regulador perguntará não se vocês pretendiam a residência de dados ou a auditabilidade, mas como provam que ela se manteve continuamente, e um pipeline verde é uma resposta muito mais forte que um documento de política. Priorizem automatizar as características cuja falha é ao mesmo tempo provável e cara e aceitem que algumas continuarão manuais.
Quando vocês decidem se um requisito é arquiteturalmente significativo, quem toma essa decisão, e como mantêm a lista de ASRs de virar ou tudo ou nada? O valor de nomear requisitos arquiteturalmente significativos vem da seletividade: trate todo requisito como significativo e o design para, trate nenhum como significativo e os estruturais, arriscados e difíceis de mudar passam sem proteção. Numa equipe grande a tentação é deixar cada esquadrão decidir localmente, o que produz barras inconsistentes e surpresas entre equipes quando a escolha “menor” de um grupo restringe a estrutura de outro. Leve a sua lista atual de ASRs, os critérios que vocês usaram (toca muitos componentes, caro de satisfazer, restrição estrita, tecnicamente arriscado) e alguns requisitos limítrofes para testar a fronteira em voz alta. Para empresas e governo, os mandatos regulatórios como residência de dados, retenção e auditabilidade são quase sempre significativos e inegociáveis, então nomeiem quem é dono da lista, como ela é revisada e como a decisão de acrescentar ou retirar um ASR é registrada, porque um ASR que ninguém governa é um requisito que ninguém defenderá sob escrutínio.

Perspectiva por setor

Startup. Mantenha a cerimônia perto de zero e o registro perto do completo. Pule as oficinas formais de ATAM e os modelos pesados, mas ainda assim escreva uma dúzia de ADRs curtos para as escolhas que seriam dolorosas de desfazer (armazenamento de dados, monólito versus serviços, provedor de autenticação) e fixe os dois ou três cenários de atributos de qualidade que os seus primeiros clientes realmente sentem. Seu recurso escasso é a atenção de engenharia, então proteja apenas as características cuja falha afundaria você, como o isolamento entre locatários, e deixe todo o resto emergente e barato de mudar.

Pequena empresa. Sem arquiteto dedicado e com orçamento apertado, apoie-se nos fundamentos que custam quase nada: nomeie seu punhado de atributos de qualidade como números concretos, escreva ADRs para tudo que você teria dificuldade de reverter e deixe a sua plataforma ou fornecedor escolhido carregar as decisões estruturais pesadas. Favoreça comprar uma pilha bem apoiada em vez de construir infraestrutura sob medida e trate a arquitetura documentada do fornecedor como uma restrição que você herda, e não uma que precise criar do zero.

Grande empresa. O desafio é a coerência entre muitas equipes e anos de roteiro, então invista em maquinário compartilhado: uma guilda de arquitetura, um conjunto comum de cenários de atributos de qualidade, ADRs guardados ao lado do código e funções de aptidão na CI que impõem fronteiras que nenhum revisor isolado conseguiria policiar em escala. Use análise estruturada de compromissos para as decisões irreversíveis e transversais, mantenha os diagramas C4 como o mapa compartilhado nas revisões de design e governe a lista de ASRs centralmente para que os grupos parem de tomar escolhas localmente razoáveis que colidem globalmente.

Governo. Sistemas regulamentados e de longa vida fazem da arquitetura documentada e defensável uma exigência de contratação e de prestação de contas, não um requinte. Trate a residência de dados, a retenção, a auditabilidade e a acessibilidade como requisitos arquiteturalmente significativos escritos numa descrição arc42 que os auditores possam ler diretamente, e conduza oficinas leves de compromissos que incluam responsáveis de política e de segurança, para que os conflitos (como cache versus auditabilidade) surjam no papel antes do código. Mantenha a trilha de raciocínio completa o bastante para que uma autoridade responsável possa mostrar a devida diligência e prefira arquiteturas com saídas claras a outras que prendam um órgão público a um único fornecedor por uma década.

Exemplos

Startup. Uma equipe de SaaS em estágio semente, com seis pessoas, mantém sua arquitetura num documento compartilhado em vez de num processo formal, mas ainda assim escreve as decisões que seriam dolorosas de reverter. Registra cerca de uma dúzia de ADRs (por que Postgres em vez de um armazenamento de documentos, por que um monólito modular em vez de serviços, por que escolheu seu provedor de autenticação) e fixa dois cenários de atributos de qualidade que de fato importam aos primeiros clientes: “um cadastro se completa em menos de dois segundos” e “nenhum cliente pode jamais ler os dados de outro locatário”. Quando contratam a sétima e a oitava pessoas engenheiras, essas notas permitem que as recém-chegadas entreguem na primeira semana em vez de interromper todo mundo para perguntar por que as coisas são como são.

Grande empresa. Um banco multinacional consolida doze sistemas regionais de pagamentos e por isso monta uma pequena guilda de arquitetura. A guilda define oito cenários de atributos de qualidade (incluindo “processar 10.000 transações por segundo sem nenhuma transação perdida” e “recuperar uma região em 15 minutos”), captura cerca de quarenta ADRs e impõe funções de aptidão na CI (integração contínua): nenhum serviço pode escrever no banco de dados de outro domínio, todas as chamadas entre serviços precisam ser rastreadas e qualquer dependência com um CVE (Common Vulnerabilities and Exposures) crítico quebra o build. Os diagramas C4 de contexto e de contêineres se tornam o mapa compartilhado em toda revisão de design, e as disputas de integração entre equipes caem de forma acentuada.

Governo. Uma agência nacional moderniza uma plataforma de benefícios, e a lei exige que ela garanta residência de dados, auditabilidade por sete anos e conformidade de acessibilidade. Seus arquitetos os tratam como ASRs e os escrevem numa descrição arc42 que os auditores revisam diretamente. Conduzem uma leve oficina de ATAM com as equipes de entrega, de segurança e responsáveis de política para comparar duas arquiteturas candidatas e descobrem que a estratégia de cache do design preferido entra em conflito com o requisito de auditabilidade. Pegar esse compromisso no papel, antes de uma linha de código, poupa meses de retrabalho e dá ao ministro responsável uma evidência documentada de devida diligência.

Justificativa de negócio: motivações, ROI e TCO

O retorno dos fundamentos de arquitetura é em grande parte custo evitado, o que o torna fácil de subfinanciar e caro de pular. O custo de adoção é modesto: algum tempo de arquitetos experientes, algumas oficinas, um modelo de documentação e algum investimento de CI em funções de aptidão, em geral uma pequena porcentagem de um dígito do orçamento de um programa. O custo de não adotá-los chega depois, e com ágio: retrabalho quando um atributo de qualidade não especificado falha em produção, replataformização de emergência quando um acoplamento não documentado bloqueia uma mudança obrigatória, incidentes arrastados porque ninguém entende o sistema e auditorias reprovadas que travam a entrega ou disparam multas.

Para a liderança, enquadre o caso em torno de opcionalidade e risco. Bons fundamentos de arquitetura reduzem o custo da mudança futura (uma alavanca direta sobre a velocidade de entrega e o custo total de propriedade ao longo da vida de um sistema de uma década), reduzem a frequência e a duração dos incidentes graves e produzem a trilha de documentação que reguladores e auditores agora exigem. Só o hábito do ADR já se paga na primeira vez em que uma nova liderança pergunta “por que construímos isto assim?” e recebe uma resposta em minutos em vez de uma investigação forense. Ponha números onde puder: pese o custo de uma grande rearquitetura evitada, ou de uma auditoria reprovada evitada, contra o pequeno custo contínuo das práticas.

Antipadrões e armadilhas

Arquitetura de torre de marfim. Arquitetos que produzem diagramas mas nunca tocam no código nem conversam com as equipes de entrega. Seus designs são ignorados ou impossíveis de construir.
Atributos de qualidade como adjetivos. “Escalável, seguro, confiável” sem números, sem cenários e, portanto, sem forma de verificar nem de trocar.
Grande design inicial. Comprometer todos os detalhes antes da primeira linha de código, fixando decisões quando a compreensão é mais fraca.
Documentação que mente. Diagramas que descrevem o sistema do ano passado. Pior que nenhuma, porque enganam.
Design guiado pelo currículo. Escolher tecnologias para construir carreiras e não para atender aos ASRs.
Banho de ouro. Projetar para uma escala, flexibilidade ou generalidade que os requisitos nunca pediram, acrescentando custo e complexidade de forma permanente.
Nenhuma proteção arquitetural. Depender de boas intenções em vez de funções de aptidão para preservar a estrutura numa equipe grande.

Modelo de maturidade

Nível 1: Iniciar. A arquitetura é implícita e vive nas cabeças dos indivíduos. Sem atributos de qualidade documentados, sem ADRs, sem diagramas compartilhados. A estrutura é descoberta durante os incidentes, e toda dependência entre equipes é renegociada do zero.
Nível 2: Desenvolver. Algumas equipes escrevem as decisões que doeria reverter e esboçam diagramas importantes, mas a prática é inconsistente: um esquadrão mantém ADRs enquanto outro não mantém nenhum, os atributos de qualidade são nomeados como adjetivos e não como cenários mensuráveis e a documentação deriva entre projetos.
Nível 3: Padronizar. Os cenários de atributos de qualidade e os requisitos arquiteturalmente significativos são especificados e priorizados segundo um padrão documentado para toda a organização. Os ADRs são rotina e ficam guardados ao lado do código, a documentação C4 e arc42 é mantida segundo um modelo comum, e revisões estruturadas de compromissos são exigidas para decisões significativas em todas as equipes.
Nível 4: Gerenciar. A arquitetura é medida em relação a linhas de base e não apenas afirmada. As funções de aptidão na CI relatam características como latência p99, violações de camadas, chamadas não rastreadas e dependências vulneráveis. A cobertura de ADRs e a atualidade da documentação são acompanhadas como métricas. As revisões de compromissos pontuam as opções contra os cenários priorizados. E a deriva em relação às linhas de base acordadas dispara uma resposta definida em vez de uma surpresa. Os auditores podem confiar em evidência medida e não apenas na narrativa.
Nível 5: Orquestrar. A arquitetura evolui continuamente e de forma adaptativa em toda a organização. Os dados das funções de aptidão e dos incidentes realimentam quais características importam e onde vai o esforço de design. As listas de ASRs, as prioridades de atributos de qualidade e as proteções são redefinidas conforme os mandatos e o risco mudam. E a prática é integrada ao planejamento de entrega, de segurança e de risco, de modo que a plataforma se adapta a novos requisitos em vez de ser reconstruída do zero.

Ideias para discussão

Quais três atributos de qualidade são genuinamente inegociáveis para o seu sistema mais crítico, e vocês conseguem declarar cada um como um cenário mensurável hoje?
Como vocês decidem quando uma decisão é “arquiteturalmente significativa” o bastante para justificar um ADR e não apenas ser feita?
Onde as funções de aptidão pegariam deriva que a sua revisão de código atual deixa passar?
A sua organização está superarquitetando ou subarquitetando, e que evidência diz qual das duas?
Quem é responsável pela arquitetura numa estrutura de equipe de equipes, e como evitar tanto as torres de marfim quanto a anarquia total?
Como um auditor externo reconstruiria a intenção da sua arquitetura a partir do que está escrito hoje?

Principais conclusões

A arquitetura é o conjunto de decisões que são caras de reverter. Faça essas trocas deliberadamente e registre-as.
Especifique os atributos de qualidade como cenários mensuráveis e identifique os requisitos arquiteturalmente significativos que moldam a estrutura.
Projete incrementalmente e proteja as características arquiteturais-chave com funções de aptidão automatizadas.
Documente de forma leve mas verdadeira usando diagramas C4, uma narrativa arc42 e ADRs por decisão guardados ao lado do código.
Ajuste o rigor ao risco: análise pesada para decisões irreversíveis e de alto impacto, processo leve em todo o resto.
O argumento de negócio é retrabalho evitado, incidentes mais curtos, mudança futura mais rápida e evidência pronta para auditoria.

Referências e leitura complementar

Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures
Simon Brown, Software Architecture for Developers (and the C4 model)
Mark Richards and Neal Ford, Fundamentals of Software Architecture
George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
Michael Nygard, “Documenting Architecture Decisions” (the ADR pattern)
Gernot Starke and Peter Hruschka, arc42 documentation template
Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
ISO/IEC 25010, Systems and software quality models