Bom pessoal, e agora a gente vai falar da tal da Service Layer, tá? E eu acho que muita gente, se você já desenvolve faz um tempo, você já ouviu falar. Camada de serviços, tá? E a primeira coisa que aconteceu comigo, tá? Quando eu li esse livro pela primeira vez, é que toda vez que eu olhava para a Transaction Script, eu pensava que a Transaction Script, eu pensava que a Transaction Script, no final do dia, era a Service Layer, mas elas são coisas distintas, apesar de serem muito parecidas. Então, vamos pensar o seguinte. Service Layer, o que é a Service Layer? Service Layer é uma camada intermediária entre a apresentação e o acesso a dados. Quando a gente recebe os dados da apresentação, a Service Layer pega esses dados, acessa os bancos de dados, executa as operações que a gente precisa e acabou. E daí você deve estar pensando, nossa, parece uma Transaction Script. Pega os dados da apresentação, realiza a transação e acabou. Vamos lá. Uma coisa importante aqui também. A Service Layer expõe funcionalidades de alto nível para os clients. O que significa os clients? Quando eu pego os dados na camada de aplicação ou quando eu estou jogando dados dentro da minha aplicação para ela executar uma lógica e resolver um problema ali para mim, é a camada de serviço que recebe essa informação e executa aquilo. E ela tem uma interface muito clara. Independente da forma de como você recebe os dados, você tem que mandar esses dados no mesmo formato para o Service Layer. Ou seja, ela tem uma interface clara para que ela consiga executar um serviço dentro da sua aplicação legal uma coisa importante lógica de negócio aonde está a lógica de negócio da sua aplicação está na série se ler tá se você perceber quando a gente está trabalhando com o domém model a lógica de negócio fica no modelo de domínio e quando você está trabalhando com o serviço e lei a lógica de negócio não fica no modelo de domínio fica na própria serve se ler tá então você vai começar a perceber que se você está trabalhando com o domém model né a você não precisa necessariamente de alguém que fique trabalhando com as suas regras, porque as regras estão expressas dentro das suas próprias entidades. Por outro lado, se você está trabalhando ali na Service Layer, você vai perceber que quando você tiver as suas entidades, as suas entidades tendem a ser anêmicas. suas entidades as suas entidades elas tendem a ser anêmicas porque porque as regras de negócio não estão mais nas suas entidades elas estão na onde na service layer ou seja normalmente quando você tem um sistema que no seu nas suas entidades têm apenas getters e setters, provavelmente você não está trabalhando com o domain model, ou seja, você tem um domínio anêmico e você está transferindo todos aqueles comportamentos, invariancias, o estado da sua aplicação para dentro da sua camada de serviço. Então, a gente tem normalmente isso bem claro. Uma coisa que é uma responsabilidade da Service Layer, no final das contas, é que ela orquestra a ordem das operações. Então, vamos imaginar que, por exemplo, você vai fazer um pedido, então ele cai num método de realizar pedido, o método de realizar pedido no serviço tem um método, verifica o estoque, e daí que ele verifica o estoque,ço tem um método a verifica o estoque e daí que ele verifica o estoque ele tem um método de aplicar fidelidade e tudo isso aí quem vai chamando é a série se leu se você tem um monte de métodos um monte de serviços que você vai utilizando agrupando para realizar um algo final legal isso é um ponto importante ponto claro também serve se ler tem acesso à camada de dados então eu quero pegar um pedido acesso a find pedido by ae de né aí ele pega find cupom by ae de daí ele cria um novo pedido daí ele executa aquele negócio e tudo ali normalmente dentro da mesma classe ou de classes que ela vai acabando compor então imagina que você tem ali um conjunto de classes que são utilizadas para executar as suas transações legal outro ponto também normalmente a service layer ela gerencia suas transações e quando falo em transações aqui eu tô falando em realização de transações de forma atômica né ou seja você começa uma transação ela termina aquela transação se deu algum erro ela compensa o que é aqui eu tô falando em atomicidade mesmo tá então o serviço ler normalmente ela trabalha dessa forma também tá agora vantagem de service layer aqui pra gente tá uma das vantagens da service layer é que você separa a responsabilidade de uma forma ou de outra você tem apresentação você tem acesso a dados a service layer ela acaba fazendo essa intermediação a service layer ela também de uma forma geral ela possui reutilização porque eu posso criar diversos serviços, os meus serviços chamam outros serviços e de acordo com como eu componho esses serviços, eu faço com que a minha regra de negócio aconteça. estabilidade melhor do que as transações script porque porque a transação script se você muda você muda o comportamento de uma transação inteira né agora no caso da série se ler você muda apenas um método por exemplo e o restante das coisas continuam funcionando né nesse método que você muda você mudou em um ele afeta em diversos lugares na transação script normalmente isso não acontece você tem que sair mudando em diversos lugares tá você tem uma flexibilidade bem grande para implementar nessa aplicação trabalha você tem ali o seu o seu serviço o seu serviço que consegue executar vários serviços você consegue utilizar utilizar e etc quais são desvantagens? Você gera uma complexidade ao longo do tempo. Por quê? Porque os seus serviços, cada vez mais, eles tendem a ficar maiores. Essas classes que organizam as suas lógicas de negócio, elas tendem a ficar muito grandes. Porque imagina, você vai realizar uma operação de realizar pedido, quanto mais passos você tem para realizar o pedido, mais complexo e maior vai ficando essas camadas de service. Eu digo isso, a gente roda um sistema aqui que tem 13 anos de idade e a gente fez ele exatamente nesse formato. A gente tem a apresentação, a gente tem a nossa service layer e a gente tem acesso ao mapeamento do banco de dados ali. E conforme o tempo foi passando, o sistema foi ficando absurdamente mais complexo. Por quê? Porque as nossas classes de serviços ficaram gigantes. Por quê? Porque ela vai absorvendo todas as responsabilidades e modelagens do sistema. Quando isso começa a acontecer, você começa a ter um acoplamento maior. Por quê? Porque você começa a gerar dependências entre serviços. Ou seja, cada pedaço de serviço começa a chamar outro serviço, que chama outro serviço. Às vezes você vai ver que gera uma dependência cíclica, que vai fazendo que um depende do outro e isso aí acaba gerando uma dependência muito ruim, então gera um acoplamento maior. E, obviamente, quando você tem classes gigantes, com muitas responsabilidades e com alto acoplamento, quando você vai trabalhar com diversas equipes, a gente tem um problema muito grande. Por quê? Porque cada equipe tem uma perspectiva de problema de resolver. E conforme essa perspectiva muda, o comportamento muda. E se você mudar o comportamento de um serviço numa parte do sistema, pode acontecer que você altere o comportamento de uma outra parte do sistema que você não deveria e no final do dia você vai começar a chegar naquela situação que mexe num pedaço quebra o outro pedaço tá e nesse caso trabalhar com modelagem de domínio ao longo do tempo se prova ser mais eficiente porque você vai estendendo o comportamento do sistema mas mantendo a coesão ea forma original de como ele ia trabalhar então nesses casos o modelo de domínio vai ajudando ao longo do tempo mas novamente modelar domínio no início é mais complexo e também é uma mudança de paradigma que o desenvolvedor tem que ter. A maioria dos desenvolvedores que eu conheço trabalham nesse formato de Service Layer. E na hora que ele tem que começar a trabalhar organizando seus modelos de domínio, é uma mudança muito complicada. Eu trabalhava somente nesse formato quando eu comecei a atender mais para a perninha do domínio Driven Design, que acaba influenciando muito essas modelagens de domínio, eu apanhei bastante até conseguir internalizar tudo isso. Então hoje em dia, dependendo da situação, eu posso trabalhar sim, posso trabalhar assado, o mais importante de tudo é você saber que você tem um grande repertório aí pela frente. Maravilha? Eu já tinha falado isso, né? Você tende a trabalhar com modelos de domínio anêmicos, né? E se você tem domínios anêmicos, você vai tende a tirar a responsabilidade das suas entidades e jogar todas as responsabilidades dentro de uma única classe. Isso aí realmente é complicado. Maravilha? Próximo slide a gente vai falar sobre um pouquinho de Service Layer versus Transaction Scripts, porque eu sei que muitas vezes isso pode gerar uma confusão. Então vamos nessa.