O termo “service” normalmente é associado a diversas coisas: sejam web services, SOAP, REST ou gRPC. Até mesmo o DDD trabalha com domain e application services.
Como esse é um termo genérico, é difícil dizer a função de uma camada service. Mas isso também depende muito de como você desenvolve a sua aplicação.
(Assista em 15min de vídeo)
Vejamos alguns exemplos mais utilizados no dia a dia:
DOMAIN SERVICE
No DDD existem diversas entidades que representam o coração da aplicação. É o produto, que tem uma categoria, com os itens e o pedido. Ou seja, são entidades que trabalham de acordo com as suas funções.
Mas trabalhar com regras de negócio exige que essas entidades se comuniquem entre si, já que por padrão elas não fazem isso. Então essa é a função de um domain service, que se responsabiliza por pegar uma ou mais entidades para aplicar uma regra de negócio.
Lembre-se que no DDD as regras de negócio ficam nas entidades, mas muitas pessoas ainda se confundem com isso. Isso é chamado de “domínio rico”, no qual o domain service faz essa amarração quando uma entidade precisa se comunicar com a outra para aplicar alguma regra.
APPLICATION SERVICE
Na função de ajustar o fluxo, se você quiser adicionar um novo cliente, por exemplo, a sua application service consegue acessar o domain service e pode utilizá-lo para fazer isso. Depois o e-mail é enviado e os dados são persistidos num banco, utilizando repositório. Então a application service aplica o fluxo de regras que a sua aplicação precisa para trabalhar.
Isso não são necessariamente regras de negócio; mas regras comportamentais do fluxo que a aplicação vai trabalhar.
Uma API Rest pode ser considerada um service exposto, tal como o gRPC ou o GraphQL.
OUTROS SERVIÇOS
Um hábito muito comum de quem não trabalha com DDD é criar uma pasta para trabalhar com todas as regras de negócio da aplicação dentro do service.
Na entidade, eles criam camadas anêmicas, que são classes que possuem apenas getters e setters, porém nenhuma regra de negócio. No fim eles deixam a entidade totalmente anêmica e adicionam todas as regras de negócio dentro desses services.
Isso não é necessariamente focado em DDD; muito pelo contrário. Mas, independente de ser certo ou errado, o que importa é o que vai funcionar e como você pode garantir que a sua aplicação seja autossustentável ao longo do tempo.
