Diretrizes da Divisão em Camadas

A divisão em camadas fornece um particionamento lógico de subsistemas em diversos conjuntos, com determinadas regras sobre como os relacionamentos podem ser formados entre camadas. Essa divisão permite restringir dependências entre subsistemas, fazendo com que o sistema seja acoplado mais livremente e, dessa forma, mantido com mais facilidade.

Os critérios para agrupar subsistemas seguem alguns padrões:

• Visibilidade. Os subsistemas só podem depender de subsistemas na mesma camada e na camada inferior seguinte.
• Volatilidade.
  • Nas camadas superiores, insira elementos que variam quando os requisitos de usuário são alterados.
  • Nas camadas inferiores, insira elementos que variam quando a plataforma de implementação (hardware, idioma, sistema operacional, banco de dados, etc.) é alterada.
  • Entre essas camadas, insira elementos que geralmente se aplicam a diversos tipos de sistemas e ambientes de implementação.
  • Acrescente camadas quando partições adicionais nessas categorias amplas ajudarem a organizar o modelo.
• Generalidade. Elementos abstratos do modelo costumam ser inseridos em camadas inferiores no modelo. Se não forem específicos da implementação, é provável que fiquem próximos das camadas intermediárias.
• Número de Camadas. Para um sistema pequeno, três camadas são suficientes. Para um sistema complexo, cinco a sete camadas costumam ser suficientes. Para qualquer grau de complexidade, o uso de mais de dez camadas deve ser visto com suspeita, que deverá aumentar com o número de camadas. Algumas regras práticas são apresentadas abaixo:

Subsistemas e pacotes em uma camada específica devem depender apenas de subsistemas na mesma camada e na camada inferior seguinte. Se essa restrição de dependências não for obedecida, a arquitetura será deteriorada e o sistema se tornará frágil e de difícil manutenção.

As exceções incluem casos em que os subsistemas precisam de acesso direto a serviços da camada inferior: convém tomar uma decisão consciente sobre como manipular serviços primitivos necessários em todo o sistema, como imprimir, enviar mensagens, etc. Não compensa restringir mensagens a camadas inferiores, se a solução for implementar efetivamente as passagens de chamadas nas camadas intermediárias.

Padrões de Particionamento

Nas camadas superiores do sistema, partições adicionais podem ajudar a organizar o modelo. As seguintes diretrizes para particionamento apresentam questões distintas a serem consideradas:

• Organização do usuário. Os subsistemas podem ser organizados em linhas que refletem a organização da funcionalidade na organização de negócios (por exemplo, o particionamento ocorre em linhas de departamentos). Em geral, esse particionamento ocorre no início do design porque um modelo de empresa existente possui uma estrutura altamente particionada no nível da organização. Esse padrão de organização costuma afetar somente as poucas camadas superiores de serviços específicos de aplicativo e normalmente desaparece à medida que o design evolui.
  • O particionamento em linhas da organização do usuário pode ser um ótimo ponto de partida para o modelo.
  • A estrutura da organização do usuário não é estável durante muito tempo (devido à reorganização de negócios) nem é uma base satisfatória a longo prazo para o particionamento do sistema. A organização interna do sistema deve permitir que ele se desenvolva e seja mantido independentemente da organização do negócio que ele suporta.
• Áreas de competência e/ou habilidades. É possível organizar subsistemas de modo que particionem responsabilidades de partes do modelo entre grupos distintos da organização de desenvolvimento. Em geral, isso ocorre nas camadas intermediárias e inferiores do sistema e reflete a necessidade de especialização de habilidades durante o desenvolvimento e o suporte de tecnologia de infra-estrutura complexa. Alguns exemplos desse tipo de tecnologia são o gerenciamento de distribuição e rede, o gerenciamento de banco de dados, o gerenciamento de comunicação, o controle de processos, etc. O particionamento em linhas de competência também pode ocorrer nas camadas superiores, nas quais é necessária uma competência especial no domínio do problema para entender e suportar a funcionalidade básica de negócios. Alguns exemplos incluem gerenciamento de chamadas de telecomunicações, negociação de valores mobiliários, processamento de indenizações de seguro, controle de tráfego aéreo, etc.
• Distribuição do sistema. Em qualquer uma das camadas do sistema, as camadas podem ser "horizontalmente" particionadas ainda mais para refletir a distribuição física da funcionalidade.
  • O particionamento para refletir a distribuição pode ajudar a visualizar a comunicação de rede que ocorrerá assim que o sistema for executado.
  • No entanto, esse particionamento também pode dificultar a realização de mudanças no sistema, se o Modelo de Implementação for alterado de forma significativa.

• Áreas de sigilo. Alguns aplicativos, principalmente aqueles que exigem autorização de segurança especial para serem desenvolvidos e/ou suportados, requerem partições adicionais nas linhas de privilégio de acesso à segurança. O software que controla o acesso a áreas de sigilo deve ser desenvolvido e mantido por pessoal autorizado. Se o número de pessoas no projeto com esse conhecimento for limitado, a funcionalidade que exige autorização especial deverá ser particionada em subsistemas que serão desenvolvidos sem depender de outros subsistemas, sendo as interfaces para as áreas de sigilo o único aspecto visível desses subsistemas.
• Áreas de variabilidade. A funcionalidade que tende a ser opcional e, portanto, liberada apenas em algumas variantes do sistema, deve ser organizada em subsistemas independentes que são desenvolvidos e apresentados sem depender da funcionalidade obrigatória do sistema.