Afinal, qual a diferença de service e action?

Olá Arthur, tudo bem com você?

Eu não sei o quão familiarizado você está com o padrão MVC, caso você prefira uma explicação mais extensa pode ler até o final. Agora, assumindo que a confusão seja por conta dos dois termos representarem "ações" (em contextos diferentes), podemos dizer Actions são ações representadas pelos métodos mapeados por um Controller, enquanto Services são classes (muitas vezes sem estado) que representam coisas intangíveis, ou seja, ações como cadastrar clientes. Nesse exemplo, poderíamos ter uma classe de serviço chamada CadastroClienteService que teria os métodos/comportamentos relacionados ao cadastro de clientes, implementando toda a lógica da aplicação nesses comportamentos, ao mesmo em que faz uso de DAOs, por exemplo, para persistir os dados da aplicação sem tocar na regra de negócio.

Caso você já tenha assistido à próxima videoaula, você já deve ter concluído a motivação por trás das Actions, correto? Os Controllers, por meio do mapeamento da URL para cada um de seus métodos, delegam às Actions a responsabilidade de lidar com as requisições que forem chegando na nossa aplicação para que assim, possamos realizar uma ação que mude o estado da nossa aplicação, seja salvando alguma informação ou simplesmente "carregando" uma nova página para ser exibida ao usuário. Até aqui, sem novidades, já os Services podem causar mais confusão por se tratar de um componente que compõe a arquitetura da nossa aplicação, assim como os Controllers.

Então, só organizando as ideias: temos a camada de visualização/apresentação (view) com os clientes que interagem diretamente com o usuário para receber e apresentar dados; temos a camada de controle (controller) que serve como camada intermediária entre a apresentação e a lógica que mapeia as ações do usuário; e, por fim, temos a camada de modelo (model) que encapsula toda a regra de negócio e que, de fato, armazena e manipula os dados da aplicação.

Bom, sabendo disso (e caso avance mais no curso), podemos concluir que os Controllers interagem com classes da camada de persistência (geralmente, repositories ou DAOs) que fazem parte do modelo para que possamos persistir dados da aplicação. Bom, é aqui que entra a camada de serviço com suas classes Services que fornecem toda a lógica necessária para que a manipulação dos dados que ocorre entra o cliente e o banco de dados respeite as regras de negócio. Dessa forma, agora temos classes intermediárias que garantem que os DAOs, por exemplo, lidem apenas com o acesso ao banco, enquanto os Services lidam com os dados que são fornecidos para os DAOs e pelos DAOs.

Fonte: https://medium.com/stackavenue/why-to-use-service-layer-in-spring-mvc-5f4fc52643c0

Perceba que dessa forma, desacoplamos os Controllers e as classes da camada de persistência, deixando que eles façam apenas suas respectivas funções de gerenciar ações do usuário e persistir dados, enquanto deixamos a lógica da aplicação focada apenas na camada de serviços.

Bom, acho que é isso. Existem muitos detalhes que você irá aprendendo na prática e estudando mais sobre DDD (Domain Driven Development), mas acredito que a base do conceito está aí! :)

Caso tenha ficado alguma dúvida ou algo que eu escrevi não fez sentido é só avisar!

Forte abraço e bons estudos!!

[Desculpa a demora na resposta]

Oi Thiago, ficou claro sim, e já era algo que eu estava esperando. No começo era difícil entender porque, de uma certa forma, parece que eles estavam fazendo a mesma coisa. Porém há vantagens em deixar uma camada intermediária 'Service' entre a 'Action' e o 'Repository'. Depois de ter terminado o curso de Spring Data e ler esta matéria que você postou, as coisas fazem mais sentido agora. Obrigado!