Salve, Deus, beleza? Continuando essa saga aqui no Domain Dreaming Design, agora nós vamos falar sobre serviços de domínio ou domain services. Eu costumo falar que esse recurso aqui também, dentro do DDD, é muito desconsiderado por nós ou muito subestimado. Nós damos valor onde? Aos agregados e as entidades. Mas serviços de domínio podem ser muito úteis para as nossas regras de negócio. Aonde que isso aqui vai entrar? Imagine que você tenha lá uma regra de negócio. Vamos pegar aqui o caso dos nossos agregados. A gente teria, pegando a venda de ingresso, vamos criar aqui uma order. Então, vou fazer lá o meu pedido da reserva. Mas, então vou fazer lá o meu pedido da reserva mas considerando que para poder fazer o pedido ali eu tenho que manipular ticket, a gente não sabe ainda como isso vai ser manipulado e tudo mais eu tenho que manipular também o evento tem tanto o evento. Tem tanto o evento quanto os spots. Todos esses três são agregados. Então o processo de fazer a reserva, que é a nossa regra de negócio, é esse o nosso objetivo aqui, fazer a reserva está sendo feito será feito no momento via web ou via um aplicativo mobile a pessoa entrou aí fez o pagamento e tudo mais. Mas pensando em refinamento dessa operação e até em reutilização dela, para que eu faça a reserva, eu tenho que puxar um número de ticket válido, verificar se o lugar do meu evento não está reservado, se o evento está disponível para poder fazer a reserva, porque às vezes eu posso ter algum tipo de bloqueio ali numa região de assentos e etc., não posso fazer a reserva, ou o evento está bloqueado por algum outro motivo. Posso ter várias restrições. Então, essa regra de negócio de fazer a reserva inclusive a gente pode até lidar com isso aqui como reserva está embutido criar essa ordem de pagamento eu poderia criar aqui dentro um reserva reservar vamos colocar sempre no infinitivo, reservar, recebendo aqui como parâmetro, ticket e o evento, poderia fazer essa situação? Você pode, ninguém vai te proibir de fazer. Mas aqui representa uma grande estabilidade para o nosso domínio, por quê? Uma vez que esses dois caras são agregados, lembra que a gente quer que agregados se relacionem com um acoplamento fraco só através do ID? eles só vão se conhecer pelo ID, para evitar que quando o agregado lá relacionado se modifique, impacte no outro agregado? Pois é. Se eu fizer essa situação aqui de receber esses agregados como parâmetro, primeiro, que olhando logo de cara, reservar ticket e evento, está até um pouco entendível que a gente precisa usar essas duas informações, mas quais informações estão sendo utilizadas para poder fazer essa reserva? A gente não sabe. Pode estar-se usando muitas informações, como poucas, mas é o que vai acontecer se ticket e se evento mudar, Mas é o que vai acontecer se ticket e se evento mudar, uma chance muito grande do reservar ser modificado também. Tem que ser modificado. Veja só, reservar, lembra que em cima das nossas camadas de responsabilidade, a compra do ingresso à reserva é algo crucial para o nosso sistema. Então, quanto mais isso aqui se modificar, correr o risco de sofrer transformações, ele está dependente de ticket de evento dessa forma, com parâmetro, faz com que esse método se torne instável e a gente não quer isso. Passar o objeto, o agregado inteiro cria um mundo de mistério em cima desse reservar. Então eu poderia chegar lá num serviço de aplicação que depois a gente vai mostrar na prática, mas o Vernon também falou, e colocar essa lógica ali difusa no serviço de aplicação. Mas pode, às vezes, acontecer de a gente ter que fazer essa reserva. Posso querer fazer essa reserva através... O cliente faz a reserva, mas eu poderia ter um momento que um funcionário da empresa faz a reserva pelo cliente, por um atendimento ou algo assim. Eu posso ter várias formas de fazer essa reserva que não é só o cliente fazendo. Então, esse reservar aqui, que envolve esses outros dois agregados, na verdade, a gente poderia delegar ao cara externo, ou melhor, a um cara intermediário, que na verdade, falando em nível de código, a gente sempre gosta de ouvir nível de código, vai ser uma classe que a gente vai criar tendendo a ter um método estático principal que vai fazer esse processamento. Então, esse fazer a reserva, ele acaba usando o agregado de reserva, o ticket e eventos. Eu posso ter aqui um método reservar, em que ele sim vai receber os parâmetros. Pode ser esses três, eu estou apenas divagando. Ou melhor, não precisa nem ser esses três. Eu posso receber assim posso receber o ticket o evento e eu retorno o que? retorno a reserva criada aqui a gente não está falando de banco de dados a gente só está falando da regra de negócio em si então, puxando para cá beleza, então agora eu tenho um serviço de domínio, ele atua no coração do nosso software, eu passo o ticket e o evento ele me devolve a reserva. Se eu precisar que um funcionário gere a reserva, ou eu tenho outros modos de gerar essa reserva, eu tenho um serviço que já faz isso. Eu não preciso replicar também toda a questão de verificação, se o evento está disponível, se o lugar está disponível, etc. Ao longo, eu não preciso ser difuso isso. Isso está centralizado. Então, se acontecer de ticket, de evento, de reserva mudar, vai impactar nos agregados? Não. Obviamente, se eles mudaram, vai impactar no meu serviados? Não. Obviamente, se eles mudaram, vai impactar no meu serviço de reservar. Essa lógica, ela não pertence, isso aqui é apenas uma ideia, não estou falando que a gente vai fazer dessa forma. Mas a gente tem muito disso. Às vezes, uma operação, um processo de negócio que não pertence necessariamente a um agregado. Então, você cria ali o serviço de domínio. O caso da reserva em si, a gente poderia trabalhar com eventos de domínio, ou melhor, com serviços de domínio, mas a gente vai ver isso na parte prática. Mas é apenas para que a gente entenda a ideia. Muitas vezes você vai processar coisas complexas ou você precisa de coisas de outros agregados, é recomendado que você não passe esses agregados com parâmetro para outro, nem que você não vá usar, você não vá armazenar ele localmente, mas você precisa de uma informação. É muito melhor que o reservar aqui no final das contas, ele receba... Ah, espera aí, eu estou querendo só o ID do ticket, né? Eu recebo aqui o ID e recebo aqui... e recebo aqui talvez o Spot ID, que é o do evento em si. E aí como ele é um agregado aqui, a responsabilidade dele é de gerar ali a data, de deixar as informações consolidadas. O reserva, o agregado de reserva, ele não sabe das restrições para poder fazer a reserva. Então essa lógica dessas restrições ficaria dentro do serviço de domínio, já que elas estão pertencendo ao próprio agregado de evento. Olha que interessante isso. Eu tenho um agregado que gerencia ali se o lugar está disponível, etc. E a reserva é onde eu vou armazenar, de fato, a reserva que foi feita. Mas para que eu faça a reserva, envolve outras informações que eu não quero acoplar dentro do meu agregado. Para você poder ver se um serviço de domínio cabe ou não, é justamente a questão de experimentação. Você vai criar os seus agregados, teste ali no meio do código, depois a gente fala mais sobre isso, e vê se faz sentido. Às vezes você está colocando alguma coisa no serviço de domínio que poderia ser colocado dentro do agregado. Mas você vê que o serviço de domínio ficou bom quando você fala justamente isso aqui pertence ao agregado em si, essas regras aqui, muitas vezes são verificações, são validações específicas que dependem de outros. Não, não depende. Então, eu não precisaria criar o serviço de domínio. Show de bola, pessoal. Vamos continuando, então, a nossa saga. É isso aí. E até a próxima.