Dividir em camadas distribui logicamente o sistema em conjuntos de subsistemas, com determinadas regras a respeito de como os relacionamentos podem ser formados entre eles. Dividir em camadas fornece uma maneira de restringir as dependências inter-subsistema, resultando em um sistema com pouco acoplamento e, conseqüentemente, de mais fácil manutenção.

Considere a quantidade e a finalidade das camadas com cuidado. Não complique demasiadamente a solução definindo mais camadas do que o necessário para atender as necessidades da solução. Mais camadas podem sempre ser adicionadas no futuro para atender novos requisitos. Remover as camadas não é sempre tão fácil e pode introduzir riscos no projeto.

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

• Visibilidade: Os subsistemas devem depender somente dos subsistemas na mesma camada e na próxima camada inferior.
• Volatilidade:
  • Nas camadas mais altas, coloque os elementos que variam quando os requisitos de usuário mudam.
  • Nas camadas mais baixas, coloque os elementos que variam quando a plataforma de implementação muda (hardware, linguagem, sistema operacional, base de dados, etc).
  • Nas camadas intermediárias, coloque os elementos que são geralmente aplicáveis a uma grande quantidade de sistemas e ambientes de implementação.
  • Adicione camadas quando divisões adicionais dentro destas categorias ajudarem a organizar o modelo.
• Generalidade: Os elementos abstratos do modelo tendem a ser colocados na parte mais baixa do modelo. Se eles não forem especificamente de implementação, tenderão a ser movidos para as camadas intermediarias.
• Quantidade de camadas. Para um sistema pequeno, três camadas são normalmente suficientes. Uma arquitetura em três camadas com Apresentação, Negócio e Dados é muito comum em sistemas de informação. Para um sistema complexo, cinco a sete camadas devem ser apropriadas. Para qualquer grau de complexidade, mais de 10 camadas devem ser visualizadas com suspeita de incremento na quantidade de camadas.

A falha em restringir dependências de acordo com os critérios de Visibilidade mencionados acima pode causar degradação arquitetural e tornar o sistema difícil de estender e manter.

As exceções permitidas à regra de visibilidade incluem os casos onde os subsistemas necessitem ter acesso direto aos serviços das camadas inferiores que estão além da camada inferior mais próxima. Tome uma decisão sobre como tratar serviços primitivos que são necessários em todo o sistema, tal como impressão, emissão de mensagens, etc. É de pouco valor restringir as mensagens para as camadas inferiores se a solução tiver que implementar eficazmente chamadas pass-through nas camadas intermediárias. Este uso de regras menos rigorosas nas dependências entre as camadas é por vezes chamado de Arquitetura em Camadas Relaxada.

Padrões de divisão

Nas camadas superiores do sistema, uma divisão adicional pode ajudar a organizar o modelo. As diretrizes para divisão a seguir apresentam diferentes questões a serem consideradas:

Organização do usuário: Os subsistemas podem ser organizados ao longo de linhas que espelhem a organização da funcionalidade na estrutura do negócio (a divisão ocorre ao longo de linhas departamentais ou de papéis de usuários). Esta divisão ocorre frequentemente cedo no design por causa de um modelo de negócio existente que é fortemente dividido de acordo com a estrutura da organização. Este padrão normalmente só afeta algumas camadas superiores de serviços específicos da aplicação e normalmente desaparece à medida que o design evolui.

• Dividir ao longo das linhas de organização do usuário pode ser um bom ponto de partida para o modelo.

• A estrutura de organização do usuário não é estável em um longo período de tempo por causa das reorganizações no negócio; conseqüentemente, não é uma boa base de longo prazo para a divisão do sistema. A organização interna do sistema deve permitir que o sistema evolua e seja mantido independentemente da estrutura de negócio que ele suporta.

Áreas de competência e habilidades: Os subsistemas podem ser organizados para dividir as responsabilidades para partes do modelo entre grupos diferentes dentro da organização do desenvolvimento. Tipicamente, isto ocorre nas camadas intermediárias e inferiores do sistema, e reflete a necessidade para especialização nas habilidades durante o desenvolvimento e suporte de uma infra-estrutura baseada em tecnologia complexa. Exemplos de tais tecnologias incluem a gestão de rede e de distribuição, a gestão de base de dados, a gestão de comunicação, o controle de processo, entre outros. A divisão ao longo das linhas de competência pode também ocorrer nas camadas superiores, onde competência especial no domínio do problema é requerida para compreender e suportar a principal funcionalidade do negócio. Alguns exemplos são: a gestão de chamada de telecomunicação, negociação de seguros, processos de reivindicações de seguro e controle de tráfego aéreo.

Distribuição do sistema: Qualquer camada do sistema pode ser mais dividida horizontalmente para refletir a distribuição da funcionalidade.

• A divisão para refletir a distribuição da funcionalidade pode lhe ajudar a visualizar a comunicação de rede que ocorrerá quando o sistema for executado.

• A divisão para refletir a distribuição pode também tornar o sistema mais difícil de alterar se o modelo de implantação mudar significativamente.

Áreas Secretas: Algumas aplicações, especialmente aquelas que necessitam de segurança especial para desenvolvimento ou suporte de forma isolada, requerem a uma divisão adicional de acordo com os privilégios de acesso de segurança. O software que controla os acessos às áreas secretas deve ser desenvolvido e mantido por pessoal com isolamento apropriado. Se a quantidade de pessoas no projeto com este conhecimento for limitada, a funcionalidade que requer o isolamento especial deve ser dividida em subsistemas que serão desenvolvidos independentemente dos outros subsistemas, com as interfaces às áreas secretas sendo o único aspecto visível destes subsistemas.

Áreas de Variabilidade: A funcionalidade que provavelmente será opcional, e conseqüentemente entregue somente em algumas variantes do sistema, deve ser organizada em subsistemas independentes que serão desenvolvidos e entregues independentemente da principal funcionalidade do sistema.