Padrões de Arquitetura de Software — Parte I
Mergulhando em padrões comuns de arquitetura de software.
Este conteúdo é uma tradução livre e resumida do livro Software Architecture Patterns, do Mark Richards.
Introdução
É muito comum que desenvolvedores comecem a codificar uma aplicação sem uma arquitetura definida para o software. Sem uma arquitetura clara e bem definida, a maioria dos desenvolvedores e arquitetos irão recorrer ao padrão tradicional da arquitetura em camadas (também conhecido como arquitetura n-tier), criando camadas implícitas, separando o código em módulos.
Infelizmente, o resultado dessa prática é um conjunto de código desorganizado em módulos que carecem de clareza em suas responsabilidades, papéis e relacionamentos uns com os outros. Este é comumente conhecido como o anti-pattern "a grande bola de lama" (big ball of mud).
Aplicações sem uma arquitetura bem definida são normalmente acopladas, frágeis, difíceis de mudar e sem uma visão clara. Como resultado, é muito difícil encontrar as características arquiteturais da aplicação sem entender completamente as entranhas de cada módulo e componente do sistema. Algumas questões básicas sobre a implantação (deployment) e manutenção são difíceis de responder: A arquitetura escala? Quais são as características de desempenho da aplicação? Quão fácil a aplicação responde a mudanças? Quais são as características de implantação da aplicação? Quão responsiva é a arquitetura?
Padrões de arquitetura ajudam a definir as características básicas e o comportamento da aplicação. Por exemplo, alguns padrões de arquitetura naturalmente entregam aplicações altamente escaláveis, enquanto outros entregam aplicações que são altamente ágeis. Conhecer as características, forças e fraquezas de cada padrão arquitetural é necessário para encontrar o padrão arquitetural que melhor atende às necessidades e objetivos de negócio.
Como arquiteto ou desenvolvedor, você precisa sempre justificar as suas decisões arquiteturais, principalmente quando se trata de escolher uma abordagem ou padrão de arquitetura. O objetivo deste texto é fornecer informações importantes para tomar e justificar essa decisão.
Arquitetura em Camadas (Layered Architecture)
Esse padrão é amplamente conhecido pela maioria dos arquitetos e desenvolvedores. O padrão de arquitetura em camadas se assemelha a estrutura tradicional de comunicação e organização encontrados na maioria das empresas, tornando uma forma natural para construção de aplicações corporativas.
Descrição do padrão
Os componentes dentro do padrão de arquitetura em camadas são organizados em camadas horizontais, cada camada com um papel específico dentro da aplicação (exemplo: lógica de apresentação ou lógica de negócio). Apesar do padrão de arquitetura em camadas não especificar o número e tipos das camadas que devem existir, as camadas mais comuns encontradas em aplicações que usam esse padrão são apresentação, negócio, persistência e banco de dados (presentation, business, persistence e database). Em alguns casos, a camada de negócio e a camada de persistência são combinadas em uma única camada de negócio, especificamente quando a lógica para persistência está dentro dos componentes na camada de negócio. Dessa forma, aplicações menores podem ter somente três camadas, enquanto aplicações maiores e mais complexas podem ter cinco ou mais camadas.
Cada camada dentro desse padrão tem uma responsabilidade e um papel específico dentro da aplicação. Por exemplo, a camada de apresentação seria responsável por tratar toda a lógica de interface com o usuário, enquanto a camada de negócio seria responsável por executar regras de negócio específicas. Cada camada forma uma abstração em volta do trabalho que precisa ser feito para satisfazer um pedido particular de negócio. Por exemplo, a camada de apresentação não precisa saber como buscar os dados do usuário, ela somente precisa mostrar as informações na tela em um formato particular. De maneira similar, a camada de negócio não precisa se preocupar como formatar os dados do usuário para exibir na tela, ou até mesmo de onde esses dados estão vindo. Ela somente precisa buscar os dados da camada de persistência, aplicar a lógica de negócio em cima desses dados (calcular algo ou agregar dados), e passar essa informação para a camada de apresentação.
Uma das características poderosas do padrão de arquitetura em camadas é a separação de responsabilidades dos componentes. Os componentes dentro de uma camada específica lidam somente com a lógica que é de responsabilidade daquela camada. Por exemplo, componentes na camada de apresentação lidam apenas com lógica de apresentação, enquanto componentes da camada de negócio, lidam apenas com lógica de negócio. Esse tipo de classificação de componentes torna mais fácil de construir modelos de papéis e responsabilidades de maneira efetiva dentro da sua arquitetura, e também torna mais fácil para desenvolver, testar, gerenciar e manter aplicações que usam esse padrão de arquitetura devido a interfaces de componentes bem definidas e escopo de componente limitado.
Considerações
O padrão de arquitetura em camadas é um padrão sólido de propósito geral, tornando-o um bom ponto de entrada para a maioria das aplicações, especialmente quando você não tem certeza qual padrão de arquitetura é o melhor para a sua aplicação. Contudo, existem várias considerações do ponto de vista de uma arquitetura quando se escolhe esse padrão.
- O primeiro ponto a considerar é o que chamamos de architecture sinkhole anti-pattern. Esse anti-pattern descreve a situação onde as solicitações fluem através de várias camadas da arquitetura, apenas como um repasse com pouco ou nenhum processamento/lógica sendo realizado dentro de cada camada. Por exemplo, vamos supor que a camada de apresentação responde a uma solicitação para buscar do usuário. A camada de apresentação passa a solicitação para a camada de negócio, a qual simplesmente repassa a solicitação para a camada de persistência, a qual então faz uma simples query SQL na camada de banco de dados para recuperar os dados do usuário. Os dados retornados são repassados de volta para todas as camadas acima sem processamento ou lógica adicional para agregar, calcular ou transformar os dados. Cada arquitetura em camada terá pelo menos alguns cenários que caem no architecture sinkhole anti-pattern. A chave, contudo, é analisar o percentual de solicitações que caem nesse anti-pattern. A regra do 80–20 é normalmente uma boa prática para encontrar se você está ou não caindo nesse anti-pattern. A ideia é basicamente você ter (no máximo) cerca de 20% das solicitações como um “repasse” entre as camadas, enquanto os 80% restantes de fato tem lógica de negócio associada a solicitação. Porém, se você perceber que essa taxa está invertida, você pode considerar manter algumas camadas abertas (para serem “puladas”), mas tenha em mente que será mais difícil controlar as mudanças e manter o isolamento das camadas.
- Outra consideração com o padrão de arquitetura em camadas é que ele tende a tornar as aplicações monolíticas por si só, mesmo se você dividir as camadas em unidades de deploy separadas. Enquanto isso pode não ser uma preocupação de algumas aplicações, pode gerar alguns problemas relacionados a deployment, confiabilidade e robustez no geral, desempenho e escalabilidade.
Análise do padrão
- Agilidade Geral
Classificação: BAIXA
A agilidade geral é a capacidade de responder rapidamente a um ambiente de mudanças constantes. Enquanto as mudanças podem ser isoladas através da característica de isolamento das camadas desse padrão, ainda é complicado e demorado fazer alterações nesse padrão de arquitetura devido a natureza monolítica da maioria das implementações, bem como ao acoplamento de componentes normalmente encontrados com esse padrão.
- Fácil de Implantar
Classificação: BAIXA
Dependendo de como você implementa esse padrão, você terá problemas com deployment, especialmente para aplicações grandes. Uma pequena mudança em um componente poderá exigir um redeploy da aplicação inteira ou (ou uma grande parte dela), resultando em deploys que precisam ser planejados, agendados e executados durante horários menos críticos ou em finais de semana. Dessa maneira, esse padrão não é facilmente adaptável para um pipeline de entrega contínua, reduzindo ainda mais a frequência de deploys.
- Testabilidade
Classificação: ALTA
Pelo fato dos componentes pertencerem à camadas específicas dentro da arquitetura, outras camadas podem ser “mockadas”, tornando esse padrão relativamente fácil para testar. Um desenvolvedor pode mockar um componente de apresentação para isolar os testes dentro de um componente da camada de negócios, ou mockar a camada de negócios para testar determinada funcionalidade da camada de apresentação.
- Desempenho
Classificação: BAIXA
Embora seja verdade que algumas aplicações desenvolvidas com o padrão de arquitetura em camadas tenham bom desempenho, esse padrão não serve para aplicações que exigem alto desempenho devido a “ineficiência” de ter que passar por várias camadas da arquitetura para atender a uma solicitação de negócio.
- Escalabilidade
Classificação: BAIXA
Por causa da tendência de implementações fortemente acopladas e monolíticas deste padrão, as aplicações construídas usando esse padrão arquitetural são geralmente difíceis de escalar. Você pode escalar uma arquitetura em camadas dividindo as camadas em deployments físicos separados ou replicando a aplicação inteira em múltiplos nós, mas no geral, a granularidade é muito ampla, tornando muito caro para escalar.
- Fácil de Desenvolver
Classificação: ALTA
Esta categoria “Fácil de Desenvolver” é classificada como alta, porque o padrão de arquitetura em camadas é amplamente conhecido e não tão complexo de implementar. Devido a maioria das empresas desenvolverem aplicações separando as skills em camadas (apresentação, negócio, banco de dados), esse padrão torna-se natural para o desenvolvimento da maioria das aplicações corporativas. A conexão entre a estrutura de comunicação e organização da empresa e a forma como ela desenvolve o software é demonstrado no que é chamado de Lei de Conway.
Continue a leitura na Parte II — Arquitetura Orientada a Eventos.
Se você gostou desse conteúdo, não deixe de compartilhar. 😉
