Uma dos temas mais controversos sobre Arquitetura de Software é, exatamente, do que ela trata. Nesse primeiro vídeo, propomos uma definição que ainda será revisitada e expandida ao longo da série.

Definir e atender atributos de qualidade, bem como respeitar restrições é fundamental para definição correta de uma boa arquitetura de software. Muitas vezes, as decisões vão implicar na resolução de trade-offs.

Geralmente, quando alguém diz que vai “apresentar” a arquitetura de um software, está falando dos contêineres. Também, quando alguém pede para “ver a arquitetura”, está se referindo, geralmente, aos contêineres.

Qual o papel do arquiteto de software? Ele é sempre necessário? Ele programa? Ele é um “Dev Sênior-Sênior”? O que é necessário saber para ser um bom arquiteto? Respostas para essas e outras perguntas, nesse vídeo.

Projetar a arquitetura sem levar em conta a estrutura da organização que o irá desenvolver é ingenuidade – essa é a principal lição da lei de Conway para arquitetos de software.

Qual é o tipo de documentação necessário para expressar a arquitetura? O código não é suficiente? E os testes? Aliás, preciso me preocupar com documentação?

O que há de comum em qualquer discussão sobre arquitetura, independente do projeto, empresa ou expertise do time? Seguramente, considerações sobre três fatores: custo, complexidade e acoplamento.

Um dos maiores “pecados” da prática arquitetura ingênua de software é desprezar os impactos do tempo e das mudanças na aplicação.