14 padrões de arquitetura de software

Marcos de Benedicto (Bene)
4 min readDec 7, 2022

O padrão Circuit Breaker minimiza os efeitos de um perigo ao redirecionar o tráfego para outro serviço. Embora ajude a tornar os sistemas mais tolerantes a falhas para evitar acidentes, também requer testes sofisticados e o uso de uma tecnologia de gerenciamento de infraestrutura como a malha de serviço.

O padrão Cliente-Servidor é uma arquitetura ponto a ponto composta por um cliente, que solicita um serviço, e um servidor, que fornece o serviço. Exemplos incluem serviços bancários, compartilhamento de arquivos, e-mail e a World Wide Web. Uma vantagem desse padrão é que os dados e os periféricos de rede são gerenciados centralmente, no entanto, o servidor é caro.

O padrão Segregação de Responsabilidade de Consulta de Comando (CQRS) lida com a situação em que as consultas de banco de dados ocorrem com mais frequência do que as mudanças de dados. Ele separa as atividades de leitura e gravação para fornecer maior estabilidade, escalabilidade e desempenho, mas requer mais tecnologias de banco de dados e, portanto, pode aumentar os custos.

O padrão Controller-Responder divide a arquitetura em dois componentes: O controlador manipula os dados e distribui as cargas de trabalho, e o respondente replica os dados do controlador e gera resultados. Uma vantagem é que você pode ler dados do respondente sem afetar os dados no controlador, mas se o controlador falhar, você pode perder dados e precisar reiniciar o aplicativo.

O padrão Event Sourcing é bom para aplicativos que usam dados em tempo real. Ele envia um fluxo contínuo de mensagens para um banco de dados, servidor web, log ou outro destino. É muito flexível, mas exige uma infraestrutura de rede altamente eficiente e confiável para minimizar a latência.

O padrão Layered é bom para e-commerce, desktop e outros aplicativos que incluem grupos de subtarefas executadas em uma ordem específica. O padrão em camadas facilita escrever aplicativos rapidamente, mas uma desvantagem é que pode ser difícil dividir as camadas posteriormente.

O padrão Microservices combina padrões de design para criar vários serviços que funcionam de forma interdependente para criar um aplicativo maior. Como cada aplicativo é pequeno, é mais fácil atualizá-los quando necessário, mas a complexidade significa que você precisa de mais experiência em arquitetura para fazer tudo funcionar corretamente.

O padrão Model-view-controller (MVC) divide um aplicativo em três componentes. O modelo contém os dados do aplicativo e a funcionalidade principal; a view exibe dados e interage com o usuário; e o controlador lida com a entrada do usuário e atua como mediador entre o modelo e a exibição. Esse padrão permite que o aplicativo gere várias visualizações, mas suas camadas de abstração aumentam a complexidade.

O padrão Pub-sub envia (publica) mensagens relevantes para locais que se inscreveram em um tópico. É fácil de configurar, mas mais difícil de testar porque as interações entre o editor e o assinante são assíncronas.

O padrão Saga é usado para transações com várias etapas, como serviços de reserva de viagens. Uma “saga” inclui as várias etapas que devem ocorrer para que a transação seja concluída. Esse padrão permite que as transações (idealmente com cinco ou menos etapas) ocorram em ambientes orientados a mensagens fracamente acoplados, mas requer muita programação e pode ser complexo de gerenciar.

O padrão Sharding segmenta dados em um banco de dados para acelerar comandos ou consultas. Ele garante que o armazenamento seja consumido igualmente entre as instâncias, mas exige um administrador de banco de dados qualificado e experiente para gerenciar o sharding com eficiência.

O padrão de hospedagem de conteúdo estático é usado para otimizar o tempo de carregamento da página da web. Ele armazena conteúdo estático (informações que não mudam com frequência, como a biografia de um autor ou um arquivo MP3) separadamente do conteúdo dinâmico (como preços de ações). É muito eficiente para fornecer conteúdo e mídia que não mudam com frequência, mas as desvantagens incluem consistência de dados e custos de armazenamento mais altos.

O padrão Strangler é usado quando você está fazendo alterações incrementais em um sistema. Ele coloca o sistema antigo atrás de um intermediário para dar suporte à transformação incremental, o que reduz o risco em comparação com mudanças maiores. No entanto, você precisa prestar muita atenção ao roteamento e ao gerenciamento de rede e certificar-se de ter um plano de reversão caso as coisas dêem errado.

O padrão Throttling (ou limitação de taxa) controla a velocidade com que os dados fluem para um destino. Geralmente é usado para evitar falhas durante um ataque distribuído de negação de serviço ou para gerenciar custos de infraestrutura de nuvem. Para usar esse padrão com sucesso, você precisa de bons mecanismos de redundância, e geralmente é usado junto com o padrão do disjuntor para manter o desempenho do serviço.

Fonte (Vicki Walker — RedHat) : https://www.redhat.com/architect/14-software-architecture-patterns

--

--

No responses yet