Quão essencial é fazer uma camada de serviço?

O livro de Martin Fowler "Padrões de Arquitetura Empresarial" declara:

The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...]

But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.

Os benefícios que uma Camada de Serviço oferece é que ela define um conjunto comum de operações de aplicativo disponíveis para diferentes clientes e coordena a resposta em cada operação. Onde você tem um aplicativo que possui mais de um tipo de cliente que consome sua lógica de negócios e tem casos de uso complexos envolvendo vários recursos transacionais - faz sentido incluir uma camada de serviço com transações gerenciadas.

Com o CRM, Vendas e Inventário, haverá muitos casos de uso do tipo CRUD, dos quais quase sempre há correspondência de um para um com as operações da Camada de Serviço. As respostas à criação, atualização ou exclusão de um objeto de domínio devem ser coordenadas e transacionadas atomicamente pelas operações da Camada de Serviço.

Outro benefício de ter uma Camada de Serviço é que ela pode ser projetada para invocação local ou remota, ou ambas - e oferece a flexibilidade para isso. O padrão estabelece as bases para a implementação encapsulada da lógica de negócios de uma aplicação e a invocação dessa lógica por vários clientes de maneira consistente. Isso significa que você também reduz / remove a duplicação de código, pois seus clientes compartilham os mesmos serviços comuns. Você pode potencialmente reduzir os custos de manutenção também - como quando sua lógica de negócios muda, você (geralmente) só precisa alterar o serviço, e não cada um dos clientes.

Em resumo, é bom usar uma camada de serviço - mais eu acho que, no exemplo que você forneceu, parece que você tem vários clientes de lógica de negócios.

Adicionando uma camada de serviço porque você avaliou a ideia e concluiu a melhor abordagem: good

Adicionando uma camada de serviço, porque é isso que todos os garotos legais estão fazendo: bad

Se seu intestino disser que você não precisa de um, então não faça um.

Não há nada errado ou certo com uma camada de serviço - é uma abordagem específica cuja adequação deve ser avaliada em seus méritos técnicos para o projeto em questão. Não se sinta obrigado a substituir as opiniões de outras pessoas pelo seu próprio julgamento.

Existem muitos fatores que influenciam na decisão de criar uma camada de serviço. Eu criei camadas de serviço no passado pelos seguintes motivos.

1. Código que precisa ser reutilizado por vários clientes.
2. Bibliotecas de terceiros para as quais temos licenças limitadas.
3. Terceiros que precisam de um ponto de integração em nosso sistema.
4. Centralizando a lógica de negócios duplicada.

Caso 1: você está criando uma funcionalidade básica que precisa ser usada por uma infinidade de clientes diferentes. A camada de serviço baseia-se na funcionalidade para que diferentes clientes utilizem sua funcionalidade fornecida imediatamente.

Caso 2: normalmente você hospeda código no espaço do aplicativo, mas está usando uma biblioteca de terceiros para a qual você tem licenças limitadas. Nesse caso, você tem um recurso que gostaria de usar em todos os lugares, mas apenas um número limitado deles. Se você hospedá-lo por trás de um serviço, toda a sua organização poderá utilizá-lo em seus aplicativos sem ter que comprar uma licença para cada hospedagem individual.

Caso 3: Você está criando funcionalidade para terceiros se comunicarem com você. No seu exemplo, você poderia configurar um endpoint de estoque para permitir que os fornecedores passem mensagens para você sobre as remessas de produtos recebidos.

Caso 4: Você analisou seu código em toda a empresa e descobriu que equipes separadas criaram a mesma coisa (implementadas apenas de forma ligeiramente diferente). Com uma camada de serviço, você pode escolher a (s) melhor (s) abordagem (s) e agora você pode implementar o mesmo processo em todas as equipes fazendo com que elas chamem o serviço. Outro benefício para centralizar a lógica é quando os erros são encontrados. Agora você pode implantar a correção uma vez e todos os clientes aproveitam o benefício ao mesmo tempo.

Tudo isso dito há potenciais negativos para uma camada de serviço.

1. Adiciona a complexidade do sistema. Onde antes você só tinha um aplicativo para depurar agora você tem dois. Os problemas de produção exigem a verificação da configuração do aplicativo do cliente, configurações do aplicativo de serviço ou problemas de comunicação entre aplicativos de cliente e servidor configurados corretamente. Isso pode ser complicado se você nunca fez isso antes.
2. Um ponto de falha. Se você tiver uma interrupção de serviço, todos os clientes serão afetados. Quando o código não é implantado dessa maneira, o risco pode ser menor (embora haja maneiras de atenuar isso).
3. O controle de versão pode ser mais difícil de fazer. Quando você tem um aplicativo usando uma interface de implantação de serviços, as alterações podem ser feitas ao mesmo tempo entre as duas. Quando você tem vários clientes agora, você deve gerenciar quem está na V1, quem está na V2 e coordenar a remoção da V1 (depois que você souber que todos atualizaram para a V2).

O ponto principal é que nem sempre é um slam dunk para orientar o serviço do sistema. Na minha experiência, geralmente é uma boa idéia (eu tenho a tendência de estruturar aplicativos dessa maneira), mas não é uma decisão automática. No final do dia, você precisa avaliar os prós e contras e tomar a decisão certa para a sua situação.

A maioria das camadas de serviço que vi são uma bagunça completa. Os serviços tendem a ter muitos métodos diferentes, 1500 LOC não são raros. Os diferentes métodos não têm nada em comum, mas compartilham código. Isso resulta em um alto acoplamento , baixo coesão . Também viola o OCP , porque toda vez que uma nova operação é necessária, você precisa modificar o código em vez de estender o base de código. Uma camada de serviço bem construída é teoricamente possível, mas nunca a vi na prática.

CQRS soluciona esses problemas e impede que você tenha que criar uma dessas camadas de serviços procedurais.

Adicionar uma interface (uma camada de serviço é um tipo de interface) leva tempo. Uma boa leva muito tempo para projetar e testar. É muito importante acertar na primeira tentativa, porque alterá-lo posteriormente quebra todos os clientes. Além disso, considere que você provavelmente não saberá o que precisa estar nessa interface até ter um segundo cliente com necessidades ligeiramente diferentes. Manter um serviço é um projeto sem fim em si mesmo.

Na maioria das organizações, se você for ao seu patrocinador de negócios e perguntar a eles: "Você quer que outros departamentos obtenham o benefício de (reutilizar) esse sistema que estamos desenvolvendo com o seu orçamento?" eles vão rir de você. Comece a trabalhar para o seu patrocinador de negócios primeiro, depois comece a mexer com esse código (no tempo do seu departamento).

Se você sabe, de fato, que a funcionalidade que está escrevendo hoje será reutilizada por vários clientes de serviços diferentes, considere projetar uma camada de serviço desde o primeiro dia. Se você não tiver certeza, ou se houver muitas incógnitas no projeto, obtenha algo simples trabalhando primeiro e separe-o em serviço e cliente mais tarde, se tiver tempo e orçamento. É muito mais fácil obter a interface de serviço logo na primeira tentativa quando você inicia com um sistema em funcionamento.

P.S. Se você está trabalhando em Java, Joshua Bloch tem muitos conselhos fantásticos de interface em todo o seu livro, Effective Java.

Eu concordo com você. Não há necessidade de incluir mais uma camada se você estiver usando uma única interface do usuário.

DAL, BL e UI / Controller são uma boa combinação para projetar um aplicativo. Se você planeja usar uma única interface do usuário, não há necessidade de preparar uma camada extra. Incluir mais 1 camada no aplicativo só aumenta os esforços de desenvolvimento / tempo.

Outro exemplo é usar várias interfaces de usuário em seu aplicativo, é bom ter uma camada de serviço para lidar com interfaces de usuário neste caso.

Stack Overflow: Discussão sobre o padrão da camada de serviço

Eu contestaria que o seu BL é a sua camada de serviço. Um lugar central onde sua lógica de negócios está. Esta deve ser uma DLL que pode ser usada por qualquer coisa que precise dessa lógica. Em seguida, você pode colocar uma camada de API da web sobre ela, caso seu aplicativo tenha diferentes IUs.