Salve, Deus, beleza? Continuando ou finalizando quase a nossa saga aqui de Domain Dream Design, agora vamos falar sobre os Application Services, que eu comentei isso lá nas aulas, mas eu queria deixar uma aula registrada para ficar fácil de vocês acharem, principalmente aqui sobre a questão do nosso agregado de eventos, que nós temos tudo concentrado nesse Application Service chamado de Event Service. Ah, eu tenho um agregado de event service. Eu preciso criar um application service para concentrar tudo ali? Não necessariamente. Eu falei isso lá atrás nas aulas. Como a gente tem várias necessidades em cima desse agregado, eu quero pegar somente os spots, quero pegar somente as sessões, eu posso criar application services que tem um nome event section service event spot service o application service, ele está muito ligado às necessidades de usuários, dos usuários do sistema. Então, você vai ver ali o que os Domain Experts precisam, o que os Stakeholders precisam, e aí você cria ali a classe e os devidos métodos. Então, aqui, na verdade, até seria melhor que a gente separasse em outros Application Services também, um pelo menos para o section e outro para o spot, porque aí ficaria mais diluído essas questões. Não tem problema nenhum. Não é porque estou tudo concentrado no agregado que no serviço de aplicação eu não posso fazer essa segregação, porque senão também ele vai ficando grande demais e a gente perde o controle. Mas aqui no caso, vamos imaginar que nós temos um outro problema, porque eu tenho três tipos de usuários. Lá no nosso Event Storming, a gente não colocou que nós temos três tipos de usuários. Eu tenho o admin, o parceiro e o cliente. E o cliente. Então, eu vou concentrar todas as necessidades deles dentro de um application service? Não. Como eu poderia fazer essa organização? A gente poderia fazer uma organização baseada em um nome específico, em um objetivo ou até em um nome de usuárioário. Então a gente poderia ter, por exemplo, aqui um admin, um customer e um partner. Uma coisa, os consumidores vão ver os eventos de uma forma, mas vamos olhar aqui uma forma que entra muito em disputa, que é o administrador da plataforma e os próprios partners. Eu poderia criar aqui um admin event-service.ts. admin event-service.ts eu poderia ter aqui também um partner event-service ou algum nome que deixe claro a intenção disso aqui. Então, eu posso criar os application-services separados por área ou separados por usuários, porque aí eu concentro essas necessidades dentro desse application service. Então, não dá para misturar tudo dentro do mesmo arquivo aqui. Ah, eu tenho... Uma coisa é o administrador consultando os eventos, outra coisa é o parceiro, porque o parceiro não vai conseguir ver todos os eventos. Ele vai conseguir só ver os eventos relacionados com ele. Aí você faria um filtro aqui muito grande e acaba se perdendo o controle então às vezes a gente pode imaginar que teriam algumas coisas repetidas nesses application services, alguns métodos de consulta por exemplo, mas aí eu parafraseio o Uncle Bob, essa duplicação que pode acontecer é uma duplicação acidental. Ela é momentânea também. À medida que você vai evoluindo com o software, porque o motivo dos dois métodos, apesar do código estar igual, o motivo para a mudança é diferente. Então, ao longo do tempo, tendem a ser diferentes. E aí a gente não vai se importar mais com isso. O problema é a... Na verdade, não é dúvida. Duplicação. Duplicação. Quando a duplicação é intencional, que é o problema. Então, eu poderia ter esse cenário aqui. Então, fique ligado com isso. Veja os contextos que você tem que ter e Application Service atende aos clientes. Ele está ali para que pessoas utilizem, para elas terem uma camada que organiza todas as regras independentes de negócio que estão ali nos próprios agregados. Então, pessoal, vamos continuar nossa saga. É isso aí e até a próxima.