As boas práticas em arquitetura de software envolvem um conjunto de métodos, habilidades e conhecimentos para que o processo de desenvolvimento seja eficiente, organizado, sustentável no longo prazo e de qualidade, reduzindo riscos de fracasso. Neste artigo, você vai saber o que é arquitetura de software, os modelos de arquitetura mais comuns e como escolher a arquitetura de software adequada ao seu projeto.
O que é arquitetura de software?
Arquitetura de software é a estrutura que define os componentes computacionais de um sistema e os relacionamentos entre eles; os padrões e restrições que guiam a sua composição.
A arquitetura envolve todas as decisões sobre as estruturas do sistema, controle, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidades e determina os elementos visíveis, escalabilidade, desempenho e outros atributos de qualidade.
A arquitetura de software adequada ajuda também a evitar diversos problemas ao longo das etapas do processo de desenvolvimento.
Por exemplo, a arquitetura de um edifício depende de sua finalidade (tal como um prédio residencial e uma fábrica têm estruturas e aparências diferentes). De forma similar, a escolha da arquitetura de software também é determinada pela finalidade do seu projeto.
Mas projetar a arquitetura de softwares é mais variável do que esta metáfora sobre arquitetura de edifícios. Prédios são estáticos e o trabalho dos arquitetos é feito apenas uma vez. O software, por sua natureza, é mutável e dinâmico.
Isso quer dizer que a arquitetura de software deve ser definida, planejada e projetada antes do início do desenvolvimento. Assim como um prédio não é construído sem plantas arquitetônicas, você não deve desenvolver um software sem mapear claramente as características de sua arquitetura.
Leia também: - A Importância da Arquitetura de Software
Porque devemos aplicar as boas práticas?
Para que todo o complexo fluxo de trabalho visto até aqui resulte em um software consistente e de qualidade, é importante que a empresa desenvolvedora de software adote boas práticas recomendadas, independente do modelo de desenvolvimento – em cascata ou ágil.
“A arquitetura de software precisa ser voltada para o negócio, com foco nas necessidades do cliente. Não há modelos prontos. Por exemplo, o cliente precisa de um sistema com respostas rápidas. O foco aqui deve ser no desempenho, o quanto esse software vai exigir de recurso. Nesse caso, o ideal é desenvolver um software customizado.”
explica Arthur Teixeira, COO da UDS Tecnologia.
Há uma série de processos e infraestruturas que caracterizam uma arquitetura de software bem feita, tais como microsserviços, serverless, codeless, IaaS, TDD (Test-Driven Development, Desenvolvimento Orientado a Testes), BDD (Behavior Driven Development, Desenvolvimento Orientado a Comportamento), Integration Patterns, Arquitetura Evolutiva, Design System e outras práticas.
Tudo isso depende das características, dos objetivos e do escopo do projeto.
“Você pode fazer um livro de mil páginas, com uma longa história e vários personagens (modelo monolítico – Waterfall), um livro de crônicas ou ainda fazer um livro curtinho, com um personagem (modelo Agile). O modelo depende muito da proposta do projeto. A arquitetura poderá ou não utilizar microsserviços, por exemplo. A decisão depende do que o cliente precisa e do orçamento de que ele dispõe.”
compara Arthur Teixeira
Por exemplo, um projeto de aplicativo para e-commerce pode não ser funcional se ficar lento durante a Black Friday. Se o foco for no alto desempenho mesmo sob uma tempestade de acessos, isso precisa ser contemplado nos requisitos.
Quais são as boas práticas em Arquitetura de Software?
O impacto da escolha do modelo arquitetural influencia aspectos do software como por exemplo:
- Performance,
- Qualidade,
- Facilidade de manutenção,
- Portabilidade,
- Flexibilidade
- Escalabilidade
- Observabilidade
Dentre todos esses, os que merecem destaque são a Escalabilidade e Observabilidade.
A escalabilidade é a medida de flexibilidade para aumentar ou diminuir as capacidades do software de lidar com o aumento ou diminuição de cargas de trabalho, adicionar ou remover usuários com o mínimo impacto de custo.
Para ser escalável, é necessário que o sistema possa sofrer alterações de forma localizada sem afetar outras partes.
Observabilidade é uma característica de um software cujo comportamento pode ser observado e analisado por indicadores e métricas enquanto ele funciona. Essas informações estratégicas e bem detalhadas ajudam a resolver os problemas observados. Ninguém deseja ter uma aplicação com bugs, respostas lentas e outros comportamentos indesejados.
Com a observabilidade, é possível avançar para um alto grau de detalhamento sobre o comportamento de um software e entender tudo o que está acontecendo no desenvolvimento ou uso deles. A partir disso, fica mais fácil antever falhas e propor melhorias.
Mas para colher resultados de boas práticas como escalabilidade e observabilidade é fundamental definir esses critérios desde o início do projeto.
Esse foi o caso da plataforma de educação financeira Finclass do Grupo Primo, que reúne todas as boas práticas de arquitetura de software aqui elencadas. O aplicativo conta com uma estrutura própria de streaming (inclusive em 4K), com qualidade cinematográfica de conteúdo e sem indisponibilidades, já que o objetivo é alcançar mais de 1 milhão de assinantes. A plataforma foi criada a partir dos recursos Amazon Web Services (AWS), com alta velocidade de entrega dos conteúdos, em ambiente sempre disponível e altamente seguro.
Confira a íntegra do case Primo Rico no blog.
O Processo de Arquitetura de Software
Padrões de Arquitetura de Software
Os padrões de arquitetura de software são modelos que podem ser reutilizados, contribuindo para uma estrutura escalável, extensível e otimizada.
Cada modelo é uma solução testada e documentada de um problema recorrente e ajuda na tomada de decisões do projeto, como sua utilidade, funções e relacionamento com cada subsistema.
Existem diversos padrões de arquitetura de software.*
Arquitetura em camadas (Layered pattern): Os componentes são organizados em camadas horizontais e cada uma delas desempenha um papel específico na aplicação. Estes componentes são interconectados, porém independentes entre si.
O número de camadas depende da dimensão das aplicações: as pequenas possuem por volta de 3 camadas; as mais complexas têm em torno de 5 ou mais.
MVC (Model-view-controller): É focado no reuso de código e tem 3 camadas separadas, mas interconectadas: modelo (manipulação da lógica de dados), a visão (a interface do usuário) e o controlador (fluxo de aplicação).
Arquitetura de microsserviços (Microservices pattern): Consiste em uma coleção de pequenos serviços independentes, sendo que cada serviço é uma base de código separado e deve implementar uma única funcionalidade em um contexto limitado.
Service-Oriented Architecture (SOA), ou Arquitetura Orientada a Serviços: É um padrão de arquitetura de software em que os componentes são reutilizáveis e também disponibilizados na forma de serviços (unidade ou conjunto de funcionalidades do software).
Publish-Subscribe (Pub/Sub): Este modelo é baseado no envio de mensagens dos Publishers (Publicadores) para Subscribers (Assinantes) em um processo feito de forma assíncrona. Os assinantes tendem a receber os tipos de mensagens dentro de interesses expressos. Redes sociais como o Instagram e Spotify são arquitetadas neste modelo e vários fornecedores de cloud a oferecem (Google Cloud, Amazon AWS e Microsoft Azure).
* Dependendo dos objetivos do software, os padrões podem ser combinados.
Como escolher a arquitetura de software adequada?
A influência da arquitetura se estende por todo o ciclo de vida do software. Ela define um conjunto de fatores considerando velocidade e o custo de implementação, a necessidade de possíveis mudanças no futuro, metas de uso e escala do software, além de recursos para dimensionar equipes.
Aqui estão alguns pontos fundamentais que servem como parâmetros da arquitetura mais adequada e sustentável para o seu projeto.
- Conhecer os requisitos de alto nível e riscos potenciais. Os requisitos de alto nível respondem à pergunta: “Precisamos de um software para…” e em geral são levantados junto ao cliente ou usuários.
- Identificar as necessidades de escala (quantidade de operações, volume de dados a serem transacionados, quantidade de usuários, volume de acessos, etc) que o software precisa ou precisará ter futuramente.
- Identificar as necessidades de segurança e performance que o software precisa ter, visto que o planejamento arquitetural correto influencia totalmente nesses dois quesitos.
- Definir limites para o orçamento e os prazos do projeto.
- Planejar o ciclo de vida do projeto e mantê-lo. Isso inclui adotar um processo de SDLC (Secure Development Lifecycle) que integra atividades como teste de penetração, revisão de código e análise de arquitetura em todas as etapas do processo de desenvolvimento. É um processo que ajuda a detectar falhas no início do desenvolvimento, reduzindo os riscos e custos.
2 princípios básicos para projetar arquiteturas de software
Complicar é fácil, simplificar é difícil.
Em arquitetura de software, complicar é introduzir elementos e abstrações que tornam o desenvolvimento mais propenso a erros – pode ser uma nova camada, a criação de muitas classes, interfaces, etc.
Como simplificar?
Há diversos princípios que podem ajudar quando consideramos acrescentar uma característica, copiar trechos de código desnecessários ou tomar uma decisão específica durante a etapa de desenho da arquitetura do software.
Os 2 principais princípios que a UDS utiliza para guiar suas decisões de arquitetura de software são:
DRY: Don’t Repeat Yourself
Repetição é desperdício. Cada funcionalidade em um projeto deve ser representada apenas uma vez. Adicionar código desnecessário diminui a sua qualidade, porque aumenta o trabalho para manter o software no futuro. A repetição no processo de desenvolvimento de software deve ser eliminada pela automação.
Suponha que o esforço para se corrigir um bug é X. Para um desenvolvedor que copia e cola o mesmo código em várias partes diferentes do programa, o esforço é X vezes a quantidade de cópias do mesmo trecho.
KISS: Keep It Simple, Stupid!
Significa manter o seu código o mais simples possível e usar o dinheiro do cliente com sabedoria. Simples assim. 😉
Requisitos: Como projetar a arquitetura de software?
Cada projeto de software tem requisitos funcionais e não funcionais que orientam sua arquitetura e permitem entregar um produto final com o qual os clientes e outras partes interessadas ficam satisfeitos.
Sem uma compreensão clara desses requisitos desde o início, a equipe de desenvolvimento corre o risco de se perder, enfatizando necessidades erradas em detrimento de outras ou usando uma quantidade ineficiente de recursos internos.
Identificar e quantificar requisitos não funcionais
Os requisitos funcionais e não funcionais são essenciais para o projeto, porque definem as características do sistema. Os requisitos não funcionais se relacionam a desempenho, usabilidade, segurança, disponibilidade e manutenção do software.
Mas em arquitetura de software é preciso especificar e limitar (ou quantificar) o que é “desempenho” e outras características, como escalabilidade.
Os requisitos devem ser claros e usados para moldar o escopo do projeto. É importante ter em mente que o planejamento de arquitetura provavelmente mudará ao longo do processo de desenvolvimento; assim, o primeiro rascunho é diferente do resultado final.
A importância do controle de versão
Alterações e versões diferentes atrapalham. Para guiar o desenvolvimento, organizar o fluxo de trabalho, controlar alterações e evitar confusões no projeto, equipes ágeis costumam adotar um sistema de controle de versões distribuído.
Assim, é possível acompanhar o número de bugs, funcionalidades inseridas durante cada sprint, qual o tempo médio trabalhado em determinadas funcionalidades, além de tornar fácil a execução do CI/CD (Continuous Integration/Continuous delivery), um método de integração e entrega de aplicações com frequência aos clientes.
O sistema de controle de versão é um mapa de referência do histórico das versões anteriores e fonte de verdade que deve acompanhar todo o desenvolvimento do software até o seu lançamento. A UDS, por exemplo, utiliza o GitFlow.
Conclusão
A boa arquitetura de software ajuda a minimizar problemas, principalmente em relação ao funcionamento, desempenho, prazos e custos. Com boas práticas de design, clareza e consistência, o produto vai estar mais próximo de atender as necessidades para as quais foi especificado.
Cada projeto é único e pode combinar diferentes tipos de arquitetura de software, dependendo do objetivo do sistema e do problema que precisa ser solucionado.
Afinal, um software é um programa ou aplicação que visa resolver determinado problema e sua qualidade é definida pela capacidade em satisfazer as necessidades de clientes e usuários.
