Padrões de Arquitetura de Software
Porque deveriamos aprender sobre padrões arquiteturais? Acredito que com este conhecimento poderemos atender melhor os requisitos de negócio, nos ajuda a tomar decisões melhores na hora de escrever o código.
Arquitetura em camadas ou “Layered architecture”
É o mais comum, até por estudarmos logo cedo nas teorias da computação com outros nomes, lembra do protocolo TCP/IP? A idéia básica é dividir responsabilidades em camadas em empilhar cada uma, de maneira que a camada acima tenha acesso a imediatamente abaixo, mas a camada de baixo não consiga acessar a de cima. Fácil, não?
Se você faz uso deste estilo arquitetural, você deveria ter algo que te mostre referências ciclicas entre camadas, e até impeçaa que isto aconteça como o https://www.archunit.org/
Arquitetura orientada a eventos ou “Event-driven architecture”
A idéia aqui, é desacoplar aplicações utilizando envio e recebimento de mensagens assincronas. Também chamamos estas mensagens de eventos, que pode te fazer pensar que será necessário uma arquitetura não bloqueante, ou utilizar o modelo reativo de programação, não é o caso.
Utilizar programação reativa, ou imperativa é uma opção a parte, porém, utilizar o modelo reativo de programação junto de uma arquitetura orientada a eventos pode ajudar a aumentar a vasão de dados, melhorando o sentimento de que a performance da aplicação esta mais rápida.
Este padrão é uma das mais populares no grupo de “padrões de arquitetura de software assincrono e distribuído”, que te habilita ter maior escalabilidade, adaptabilidade e flexibilidade. Mas pode trazer um custo maior em depuração, testes e em outros pontos a depender de cada caso.
Microkernel ou Plugin architecture
Este é um padrão que admite dois componentes, um núcleo (core) e suas extensões (plug-ins). Um grande exemplo é o seu navegador (web browser) que pode ter diversas extensões.
Arquitetura de microseviços
Arquitetua de microserviços consiste em realizar a implantação separadamente de cada serviço, onde cada serviço deve idealmente conter uma responsabilidade unica. Estes serviços são independentes um ao outro, se um serviço falhar o outro não deveria falhar em cascasta.
Space-Based architecture
A ideia principal por trás do padrão baseado em espaço é a memória compartilhada distribuída para mitigar problemas que ocorrem frequentemente no nível do banco de dados. A suposição é que, ao processar a maioria das operações usando dados na memória, podemos evitar operações extras no banco de dados, portanto, quaisquer problemas futuros que possam evoluir a partir daí.
O padrão de arquitetura baseada em espaço (spaced-base architecture) é projetado especificamente para tratar e resolver problemas de escalabilidade e simultaneidade. É também um padrão de arquitetura útil para aplicativos que possuem volumes de usuários simultâneos variáveis e imprevisíveis. Resolver o problema de escalabilidade extrema e variável arquiteturalmente é frequentemente uma abordagem melhor do que tentar dimensionar um banco de dados ou adaptar tecnologias de cache em uma arquitetura não escalável.
O padrão baseado em espaço (também conhecido como padrão de arquitetura em nuvem) minimiza os fatores que limitam o dimensionamento do aplicativo. Esse padrão recebe o nome do conceito de espaço de tupla, a ideia de memória compartilhada distribuída. A alta escalabilidade é alcançada removendo a restrição do banco de dados central e usando grades de dados replicados na memória. Os dados do aplicativo são mantidos na memória e replicados entre todas as unidades de processamento ativas. As unidades de processamento podem ser inicializadas e desligadas dinamicamente à medida que a carga do usuário aumenta e diminui, abordando assim a escalabilidade variável. Como não há um banco de dados central, o gargalo do banco de dados é removido, fornecendo escalabilidade quase infinita dentro do aplicativo.
https://www.oreilly.com/content/software-architecture-patterns/
A outras questões que devem ser analisadas que fogem de qualquer explicação de um padrão arquitetural, são questões relevantes a organização como equipe, ambiente produtivo, contrat ocom cliente, modelo de negócios, habilidade dos desenvolvedores, tempo de entrega e tamanho do projeto de software.
Postar um comentário