Fundamentos de arquitetura de software

O que é arquitetura de software

“É a organização fundamental de um sistema, incorporada em seus componentes, nas relações entre eles e com o ambiente, e os princípios que guiam seu projeto e evolução” (IEEE 1471, hoje ISO/IEC/IEEE 42010).

Na prática, arquitetura são as decisões difíceis de mudar depois: como o sistema se divide, como as partes conversam, onde ficam os dados. E quase toda decisão de arquitetura é uma troca: ganhar escalabilidade costuma custar simplicidade, ganhar consistência costuma custar disponibilidade. Por isso a pergunta mais honesta de um arquiteto é “depende”, desde que venha seguida de do quê.

Tipos de arquiteto

O arquiteto de software:

• Transforma requisitos de negócio em arquitetura de aplicação.
• Orquestra desenvolvedores e especialistas de domínio.
• Domina conceitos e modelos arquiteturais e reforça boas práticas, inclusive em code reviews.
• Ajuda nos momentos de crise.
• Afeta a estrutura organizacional, como a formação de times (veja a Lei de Conway).

Pode ser um papel, uma área ou um cargo; o que importa é que alguém exerça a função.

Por que aprender arquitetura

• Entender a visão macro e micro dos sistemas da empresa.
• Conhecer mais caminhos para resolver um problema.
• Pensar no longo prazo e na sustentabilidade do software.
• Entender melhor por que as boas práticas existem.
• Ter clareza do impacto do software na organização.
• Decidir com mais segurança.

Arquitetura × design

• Arquitetura: escopo global, de alto nível. Como os componentes interagem e quais abstrações existem entre eles.
• Design: escopo local. Padrões de projeto e boas práticas dentro de cada componente.

A fronteira não é rígida: uma decisão de design que se espalha por todos os serviços (como o formato dos eventos) vira decisão de arquitetura.

Sustentabilidade de software

• Desenvolver software é caro: times de desenvolvimento e de infraestrutura custam.
• Software resolve uma dor: se não resolve um problema, não faz sentido existir.
• Software precisa se pagar: o valor gerado ao longo do tempo tem que superar o custo do projeto.
• Precisa acompanhar o negócio: comportar as mudanças estratégicas que virão.
• Quanto mais tempo no ar, mais retorno: e quanto mais sustentável, mais tarde precisará ser reescrito.
• A solução precisa ser arquitetada: software mal planejado logo precisa ser refeito.

Pilares da arquitetura

• Estruturação: uma base sólida que facilite a evolução.
• Componentização: componentes que reflitam as necessidades do negócio.
• Relacionamento entre sistemas: protocolos, segurança e resiliência.
• Governança: padrões, regras, documentação e definições claras, para o sistema não depender de pessoas específicas (veja Documentação de software).

Requisitos arquiteturais

Requisitos não funcionais que mudam a arquitetura. Dois sistemas com as mesmas funcionalidades podem ter arquiteturas bem diferentes por causa deles.

Características arquiteturais

São as “-dades” que o sistema precisa ter. Nenhum sistema maximiza todas: escolha as poucas que mais importam para o negócio e aceite as trocas. Muitas delas aparecem nos Doze Fatores.

Operacionais

• Disponibilidade: definida por SLA, SLO e SLI (veja o glossário); SRE é a prática de engenharia para garanti-la.
• Recuperação de desastres: redundância de dados, testes de backup e um plano de ação para falhas de qualquer tipo.
• Performance: ferramentas e estrutura escolhidas para atender a demanda.
• Confiabilidade e segurança: validação de dados, controle de acesso ao banco e planos contra ataques (ex.: DDoS).
• Escalabilidade: vertical ou horizontal, conforme a necessidade.

Estruturais

• Configurável: variáveis de ambiente, agnóstica ao ambiente.
• Extensível: fácil trocar bibliotecas e fornecedores.
• Fácil instalação: ambientes padronizados, pipelines, configuração de ferramentas externas gerenciada.
• Reuso: bibliotecas internas e ferramentas para desenvolvedores.
• Internacionalização: textos, mensagens de erro, moedas.
• Manutenibilidade: SOLID, padrões de projeto, estrutura clara e testes.
• Portabilidade: trocar de banco ou de provedor de nuvem sem reescrever.
• Suporte: logs, depuração e observabilidade.

Transversais (cross-cutting)

• Acessibilidade: boas práticas e padrões de design de tela.
• Retenção de dados: dados antigos em armazenamento mais barato.
• Autenticação e autorização: identity provider ou API gateway, autenticação entre serviços, políticas de segurança.
• Legal e privacidade: conformidade com as leis locais e políticas contra vazamento de dados.
• Segurança: firewall, validação de requisições, monitoramento de vulnerabilidades.
• Usabilidade: APIs desenhadas para a jornada do usuário, não só para o domínio da aplicação.

Referências

• Fundamentals of Software Architecture (Mark Richards e Neal Ford, O’Reilly): a principal referência para as características arquiteturais e para a ideia de que tudo é troca.
• ISO/IEC/IEEE 42010: o padrão que sucedeu a IEEE 1471.