O que é arquitetura de software e por que seu time deve se preocupar com isso?

Em termos simples, a arquitetura de software define a forma como um sistema trabalha e como os novos módulos podem ser construídos, e de forma intuitiva. Se pudéssemos fazer uma comparação com a arquitetura tradicional, seria assim: quando vemos a planta de uma construção, podemos supor que tipo de edifício está sendo projetado, não é mesmo?

Dessa forma, ao nos perguntarmos o que é arquitetura de software, devemos ser capazes de intuir que tipo de aplicativo será construído. Não é a mesma coisa projetar um aplicativo de gestão hospitalar do que desenvolver o sistema de um caixa eletrônico. Cada um tem um projeto de arquitetura diferente.

Ou seja, considere que o projeto da arquitetura de software se traduz na própria estrutura de pastas e pacotes – como no caso do Java – ou qualquer linguagem que seja utilizado e que ajude a expressar a intenção do sistema em si, sem informar exatamente como está feito.

Também podemos falar de “arquiteturas limpas”, que possuem uma série de objetivos em comum:

1. São independentes dos frameworks;
2. Testáveis. Baseadas em códigos que podem ser postos à prova;
3. Independentes das UI. As regras do negócio não são afetadas por um requerimento UI (User Interface).
4. Independente da base de dados. Regras de negócio independentes da implementação da base de dados. A base de dados é que se adapta às regras pré-existentes.
5. Independente de qualquer componente externo. Aplica-se a mesma regra que comentamos sobre a base de dados, mas relacionando com os componentes externos, tais como interações entre sistemas, libraries, etc.

Vantagens

Implementar a arquitetura de software nos ajuda a entender melhor do que se se trata nosso software, a focar no domínio de nosso aplicativo. Afinal de contas, este é o valor real que uma empresa de TI pode entregar aos clientes. A importância da arquitetura de software reside no fato de permitir a criação de sistemas preditivos e organizados logicamente.

Modelos ricos, baseados em nosso domínio, faz com que todos os membros da equipe compartilhem o mesmo vocabulário e coerência na hora de nomear os conceitos, o que diretamente facilita o entendimento coletivo. Também ajuda a ter um código mais fácil de manter, testar e, consequentemente, nos ajuda a atender os princípios SOLID:

Single Responsability Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Projetar a arquitetura de um software é vital para que os interesses de todos os agentes envolvidos sejam considerados. Sobre os agentes, entenda quais são: os usuários do software, o próprio software e os objetivos do negócio. Cada um deles estabelece requisitos e restrições que devem ser levados em consideração na arquitetura do software. Obviamente, em algum momento, os requisitos podem entrar em conflito.

Para os usuários, é importante que o software responda à interação de forma fluida, enquanto que para os objetivos de negócios é importante que o software custe pouco. Os usuários podem querer primeiro implementar funcionalidades úteis para o trabalho do dia-a-dia, enquanto o software pode ter prioridade na implementação de funcionalidades que permitam definir sua estrutura.

O objetivo final da arquitetura é identificar requisitos que afetem a estrutura do software e reduzir os riscos associados ao desenvolvimento do software. A arquitetura deve suportar futuras mudanças de software, hardware e funcionalidade exigidas pelos clientes (que ocorrem muitas vezes).

Vamos resumir, então, que a arquitetura de software deve ter os seguintes recursos:

• Mostrar a estrutura do software, mas sem mostrar os detalhes;
• Conceber e projetar todos os casos de uso;
• Satisfazer tanto quanto possível os interesses dos agentes;
• Cuidar dos requisitos funcionais e de qualidade;
• Determinar o tipo de software a ser desenvolvido;
• Determinar os estilos de arquitetura que serão usados;
• Abordar as principais questões transversais.

É responsabilidade do arquiteto analisar o impacto de suas decisões de projeto e estabelecer um compromisso entre os diferentes requisitos de qualidade, bem como entre os compromissos necessários para satisfazer os usuários, o software e os objetivos do negócio.