quando introduzir uma camada de serviços de aplicativos em um aplicativo de n camadas

Estou desenvolvendo um aplicativo baseado na Web, cujo objetivo principal é buscar dados do banco de dados, exibi-los na interface do usuário, receber entradas do usuário e gravá-las no banco de dados. O aplicativo não fará nenhum processamento de algoritmo de força industrial, mas receberá um número muito alto de ocorrências nos horários de pico (descrito abaixo), que serão alteradas ao longo do dia.

As camadas são as suas apresentações, negócios e dados típicos. A camada de dados é tratada pelo servidor de banco de dados. A camada de negócios conterá o componente DAL para acessar o servidor de banco de dados através do TCP. As opções que tenho para separar essas camadas em camadas são:

1. As camadas de apresentação e negócios podem ser mantidas na mesma camada.
2. A camada de apresentação em uma camada separada por si só e a camada de negócios em uma camada separada por si só.

No caso da opção 2, a camada de negócios será acessada pela camada de apresentação usando um serviço WCF por http ou tcp.

Não vejo nenhum processamento pesado sendo feito na camada de negócios, por isso estou me inclinando para a opção 1 acima. Eu também sinto pela mesma razão, adicionar um novo nível apenas introduzirá a latência da rede. No entanto, em termos de escalabilidade, caso eu precise aumentar ou diminuir, qual é o melhor caminho a percorrer? Este aplicativo precisará suportar até 6 milhões de usuários por hora. Haverá uma quantidade razoável de dados em cada sessão do usuário, armazenando as preferências do usuário e outros detalhes. Também usarei o cache no nível da página.

Eu concordo com sua avaliação inicial. Provavelmente não faz muito sentido adicionar um salto de rede adicional ao processamento do seu sistema. O motivo pelo qual as pessoas separam as camadas fisicamente é a reutilização nos aplicativos. Ou seja, você tem vários aplicativos chamando os mesmos serviços para executar uma parte do trabalho deles. Como você mencionou, não há muita lógica embutida na camada de negócios; e até agora há apenas um aplicativo usando-o.

É bom que você tenha separado as camadas logicamente, mas uma separação física no momento pode ser um exagero.

Atualização para solucionar problemas de escalabilidade

Eu ainda argumentaria que manter o BLL no mesmo nível físico da camada de apresentação é a melhor abordagem no momento. Você pode expandir adicionando mais nós de apresentação / bll (já endereçados se você estiver usando uma implantação de cliente gordo, simples o suficiente para fazer com um aplicativo Web). Além disso, se você achar que o banco de dados está se tornando um gargalo, a maioria dos bancos de dados oferece suporte a cluster / sharding e outros truques legais para expandir. Somente depois de seguir esses dois caminhos (e, claro, adicionando o cache distribuído), é que eu adicionaria outra camada física.

Antes que você possa ir para lá, eu começaria a criar uma camada de negócios mais "saudável" do que uma fachada simples para a camada de acesso a dados. A primeira etapa é considerar o uso de um O / RM poderoso que faz o mapeamento de dados para você. Em seguida, considere tornar seus objetos de negócios mais inteligentes. Existem resmas de papel escritas em Domain Driven Design (o livro é um ótimo lugar para começar). Seguir as etapas de modelagem de domínio, definir contextos limitados e encontrar raízes agregadas o ajudará a produzir uma arquitetura com costuras naturais. Isso ajudará a dividir seu aplicativo em serviços independentes que podem ser dimensionados independentemente, conforme necessário.

Suponho que você esteja usando o termo "camada" para significar um servidor físico. Se você não precisar distribuir seus negócios e a camada de apresentação, eu definitivamente evitaria isso. Enviar objetos pelo fio é caro e propenso a problemas que, se puderem ser evitados, devem. Mas você deve projetar sua arquitetura de forma a facilitar a adição de mais camadas à medida que o sistema evolui e as considerações de design justificam a distribuição. Eu normalmente desenvolvo uma camada de serviço de aplicativocomo uma biblioteca / assembly de classe que teria a mesma interface que seu serviço WCF. É isso que a camada de apresentação faz interface com ou com qualquer outro sistema externo. Se as camadas de negócios e apresentação não precisarem ser distribuídas, a camada de apresentação fará referência diretamente à biblioteca de classes. Se eles precisarem ser distribuídos, seu serviço WCF será apenas um invólucro fino em torno da biblioteca de classes da camada de serviço que fornece a capacidade de acessar o serviço remotamente.

Manter um olho no futuro geralmente é uma coisa boa, mas a introdução de uma camada de Serviço, ou qualquer coisa realmente, quando não é necessária, pode muito bem ser apenas uma perda de tempo agora, e tornar o sistema lento.

Dividir seu sistema corretamente em camadas lógicas é definitivamente uma coisa boa e permitirá que você estenda seu sistema posteriormente. A redução do acoplamento tornará mais fácil fazer isso no futuro.

Por acaso, trabalhei em um grande sistema há alguns anos atrás, que era um site -> camada de serviço -> todo o resto.

A camada de Serviço foi introduzida porque todos os arquitetos / gerentes seniores se apaixonaram por SOA; portanto, nosso sistema teve que se tornar orientado a serviços. "outros sistemas usarão a funcionalidade da camada intermediária de nossos sites" foi o clamor.

Só essa decisão custou ao projeto um ano em atrasos.