O livro "Fundamentos da Arquitetura Software: Uma abordagem de engenharia" oferece uma visão abrangente dos conceitos e ideias da arquitetura de software de forma ilustrativa e rica em exemplos.
O livro é dividido em três partes principais:
- Fundamentos
- Estilos de Arquitetura
- Técnicas e Habilidades Sociais
Parte 1: Fundamentos
A primeira parte, que compartilha o título do livro, introduz ideias que ajudam na compreensão geral do tema. É aqui onde somos apresentados também a primeira lei da arquitetura de software:
Tudo são trade-offs. Não existe uma arquitetura perfeita.
Apesar de ser a seção, bem... fundamental, também é a parte menos interessante da obra, pois ela serve meramente como um preparo para o que realmente estamos atrás: entender os diferentes estilos de arquitetura e como aplicá-los.
Parte 2: Estilos de Arquitetura
A segunda parte do livro, Estilos de Arquitetura, é a mais densa. O autor não se restringe a falar apenas a arquitetura "da moda", mas de diversos estilos de arquitetura e como eles podem ser aplicados em exemplos fictícios com requisitos reais.
Um dos exemplos que é utilizado ao decorrer do livro é um sistema de leilões, onde usuários podem dar lances, acompanhá-los, e assistir a transmissão do leilão, ministrado por um leiloeira. Apesar de parecer simples, existe uma série de sistemas que devem funcionar em sincronia: Coleta de lances, transmissão ao vivo, controle de lances, pagamentos, e sem falar em autenticação e autorização.
É exatamente o que me faz gostar muito desse exemplo: ele é diverso, complexo, e traz uma série de requisitos bastante específicos para esse tipo de sistema, com suas próprias exigências de elasticidade e desempenho.
O sistema de leilões é utilizado como base para exemplificar alguns estilos de arquitetura diferentes ao decorrer do livro, como Arquitura baseada em Eventos e Microsserviços (o queridinho atual do público), mostrando como o mesmo sistema pode ser implementado em diferentes arquiteturas. O mais interessante dessas seções como um todo é entender os trade-offs de cada alternativa e como mitigar.
Primeira regra da arquitetura: "Não existe uma arquitetura perfeita". Cada arquitetura tem seus prós e contras, e o que pode ser bom para um sistema, pode não ser para outro. O importante é entender os trade-offs e como mitigá-los.
Muitos leitores optam por não ler livros técnicos "de capa-a-capa", argumentando que é mais efetivo buscar pelos capítulos que te interessem. Para quem busca entender de forma ampla sobre diferentes estilos de arquitetura, como Arquitetura em Camadas, Arquitetura Orientada a Serviços, Arquitetura Baseada em Eventos, Arquitetura de Microsserviços, e Arquitetura de Sistemas Distribuídos, essa parte do livro é um prato cheio.
Parte 3: Técnicas e Habilidades Sociais
Essa parte do livro é especialmente útil para quem quer se tornar a figura do Arquiteto de Soluções. O autor discorre por diversos papéis que um Arquiteto de Software assume em uma equipe e como se portar. Importante notar que, para os autores, o arquiteto é também uma figura de liderança técnica, e não apenas uma figura de gestão. O arquiteto deve ser capaz de influenciar a equipe e os stakeholders, e não apenas tomar decisões técnicas sem embasamento de negócio.
Essa abordagem traz um prisma interessante para quem está buscando se capacitar como arquiteto e líder, abordando técnicas de negociação e como essa figura deve se portar dentro do ambiente profissional para florescer o melhor da equipe.
Quando buscamos livros técnicos, em geral, estamos atrás de conhecimento técnico aprofundado que possa nos ajudar a resolver problemas técnicos. Mas, em geral, esquecemos que estamos rodeado de pessoas... não apenas código. O livro mostra como pequenas mudanças de fala podem fazer uma grande diferença na forma como discussões e debates se desdobram para formar equipes colaborativas e menos ríspidas.
Uma visão assertiva sobre decisões de arquitetura
É comum que a indústria de desenvolvimento de software crie "modinhas" ao longo do caminho: tecnologias ou técnicas que são adotadas em massa, as vezes de forma... Indevida. Quando React ganhou popularidade, tudo deveria ser feito em React. Quando Rust ganhou popularidade, tudo deveria ser feito em Rust. E assim por diante.
Sites como Stack Overflow, ou até mesmo o Wikipedia, são exemplos claros de arquiteturas que sobreviveram a prova do tempo. Apesar de muito populares, mantiveram suas abordagens pois entendiam que o que era mais importante não era necessariamente adotar tecnologias novas constantemente, mas entender seus requisitos e o que é mais eficaz para resolver seus problemas.
Se interessou pelo livro? Você pode comprá-lo através deste link.
Esse artigo contém link de afiliado da Amazon. Ao clicar e comprar, você adquire um excelente livro e ainda me ajuda a comprar um cafézinho para continuar escrevendo artigos como esse. :)
