Desmistificando a Decomposição em Camadas

O tema “camadas” é recorrente na arquitetura de software: muitas vezes apontado como a solução para todo tipo de software e recentemente criticado como anti-pattern. Para os iniciantes e leigos, a arquitetura de software se resume na divisão do software em camadas e sua associação a uma “pilha” de tecnologias.

O padrão “Layers”

O padrão (pattern) “Layers”, reconhecido inicialmente em POSA 1, identifica o contexto no qual um sistema requer decomposição e se endereça a um ou mais dos seguintes problemas, conforme sintetizado por Eeles:

• Complexidade do sistema dificulta sua inteira compreensão.
• Baixa manutenibilidade – uma alteração gera uma série de impactos.
• Elementos menos estáveis não estão isolados.
• Dificuldade em identificar elementos mais reusáveis.
• Construção de um sistema por diversos times com habilidades distintas.

Tal como no conhecido Modelo OSI, o padrão “Layers” sugere um particionamento com diferentes níveis de abstração. Camadas superiores são clientes das camadas inferiores e estas não tem dependências das primeiras.

As principais estratégias para a decomposição em camadas são baseadas em responsabilidadea e reuso. Também é possível a combinação dessas estratégias em outras, como a modelagem de camadas multidimensionais.

Estratégia “Camadas com base em responsabilidades”
A estratégia com base em responsabilidades é possivelmente a mais popular, onde as responsabilidades de um sistema são isoladas umas das outras. Uma abordagem muito comum é a segmentação em camadas de apresentação, negócios e integração. A flexibilidade e manutenibilidade são os conceitos chave para esta estratégia.

Imagine que, para uma aplicação originalmente com interface web, tenha sido identificada a posterior necessidade de acesso por dispositivos móveis. Sem modificar as demais camadas, é possível oferecer uma camada de apresentação com suporte a tais dispositivos. Outra situação possível é a troca da implementação da camada de apresentação (ex: integração com mainframe para SGBD).

Esta estratégia também permite que indivíduos de habilidades distintas atuem em suas respectivas áreas de competência (ex: programadores web e integradores).

Estratégia “Camadas com base no reuso”
Geralmente derivada de uma diretriz de arquitetura corporativa, a estratégia com base no reuso sugere o agrupamento de componentes em camadas conforme o seu grau de utilização.

Um exemplo típico de estratificação por reuso,  citado por Jacobson, é o conjunto das camadas “Base”, “Específica para Negócios” e “Específica para Aplicativos”. No livro Domain Driven Design, Evan também comenta sobre a separação das camadas e usa os termos “User Interface Layer”, “Application Layer”, “Domain Layer” e “Infrastructure Layer”.

A óbvia vantagem nessa estratégia é o avançado grau de reuso de componentes. Permite também, com facilidade, o provimento e a catalogação de serviços especializados.

Estratégia Camadas multidimensionais
Combina as estratégias baseadas em responsabilidade e reuso.

Mitos “modernos” (e ingênuos) sobre camadas arquiteturais
Recentemente temos percebido um agradável movimento a favor da simplicidade das arquiteturas de software. O uso de múltiplas camadas como pouca distinção de utilidade entre elas tem gerado nomes como “arquitetura lasanha” (ressaltamos que arquiteturas são muito mais que estratificação em camadas, isto é um abuso). Simplicidade é ótimo! Mas, com devido respeito a quem cunhou o termo, o que se deve combater são as arquiteturas ritualísticas, obras criadas por indivíduos que, com pouco conhecimento em arquitetura, não exploram adequadamente o problema e que acreditam que arquiteturas de referência encontradas por aí a tudo se aplicam. O próprio contexto do pattern “Layers” define a natureza do problema no qual ele se aplica.

Muitas vezes, pouco se leva em conta as forças que regem a definição de um arquitetura. Por exemplo, suponhamos a necessidade de um software simples de cadastro sem um contexto de reuso e a ser desenvolvimento por apenas um programador. Possivelmente, o “Layers” nessa situação seria um exagero. Usar o padrão (não somente o “Layers”, qualquer um) para sem considerar todas as forças envolvidas e, principalmente, o problema que está sendo endereçado é inútil e prejudicial. Nesse caso, seria mais uma bela solução para um problema que não existe.

Boas referências sobre decomposição em camadas e assuntos correlatos podem ser encontradas em:

1. “Pattern-Oriented Software Architecture Volume 1: A System of Patterns”, Frank Buschmann e outros.
2. “Layering Strategies”, Peter Eeles
3. “Service Layer”, “Domain Model” e “Anemic Domain Model”, Martin Fower
4. “Design Patterns”, GoF
5. “Applied Software Architecture”, Christine Hofmeister, Robert Nord e Dilip Soni
6. “Arquitetura pragmática: camadas”, Ted Neward
7. “Class Type Architecture: A Strategy for Layering Software Applications”, Scott Ambler
8. “Layering Applications”, Scott Stanchfield, JavaDude.com

Para reflexão: “Ritual é o começo do caos”, Philippe Kruchten, em “The Tao of the Software Architect”.