Saudades, beleza? Continuamos essa saga aqui no Domain Dream Design. Agora nós mudamos a chave e tudo vai fazer mais sentido porque nós vamos começar aqui a trabalhar com a camada de aplicação. Esse conceito também está lá no livro do Vernon e do Evans. Olhando para essas regras de negócio, principalmente aqui do nosso agregado de eventos, que é um agregado complexo ali que tem vários objetos. A gente tem criar, publicar, mandar nome e etc. Vocês já pararam para pensar se o usuário realmente está interessado nessas regrinhas ou numa regra específica? Porque ele pode até estar interessado numa regra dessa, mas ele também está interessado que essa operação seja salva em algum lugar. O usuário não precisa conhecer o banco de dados, mas, poxa, estou fazendo ali um cadastro de um evento, tem que ficar em algum lugar, depois eu tenho que acessar isso. E a minha regra de negócio, ela não se preocupa com a questão de persistência. O meu repositório se preocupa. Então, na verdade, quando o usuário vai querer utilizar essa aplicação, ele tem mais necessidades do que os nossos agregados podem prover. Ele vai precisar usar outras camadas do nosso projeto. É aí que entra a camada de aplicação. Ela vai ser uma camada que vai orquestrar as necessidades do usuário, pegando os nossos agregados, objetos de valores, etc., formando ali a operação que o usuário, de fato, tem interesse, que satisfaz os interesses dos usuários. Então, quando a gente fala de regra de negócio em relação aos agregados, são regras que são independentes, que não necessariamente satisfazem totalmente o interesse dos usuários. Então, a aplicação une tudo. o interesse dos usuários. Então, a aplicação une tudo. Ela vai ser a camada que vai interagir com as nossas regras do coração mesmo do software, vai orquestrar, ele pode usar várias regras, e vai expor uma interface que o usuário vai usar. A gente não está falando aqui de front-end. No caso, ele vai expor métodos que o usuário vai ser capaz de usar para poder fazer o que ele precisa fazer de acordo com o interesse dele. Então, por isso que nós temos essa pastinha application aqui para poder trabalhar com essa camada de aplicação. Por isso que nós estamos trabalhando com aplicações em camadas. A gente está separando essas devidas responsabilidades. Temos já as nossas regras cruciais independentes de negócio, que não dependem de tecnologia, os repositórios, e agora vai vir a camada que vai interagir com isso. O usuário não interage diretamente com os agregados, com os repositórios. Ele sempre vai interagir com a camada de aplicação. Então, ela expõe um limite das nossas regras cruciais de negócio. Então, a gente pode criar uma application service. A gente vai chamar assim, isso é descrito nos livros dessa maneira, são serviços de aplicação que vão expor os métodos que o usuário vai interagir diretamente. Então, eu posso ter um customer service para a gente poder começar de forma bem simples. os métodos que o usuário vai interagir diretamente. Então, eu posso ter um Customer Service, para a gente poder começar de forma bem simples. E aqui eu olho, o que o usuário quer fazer com o serviço? Administradores podem querer listar esses consumidores, e os próprios consumidores, os próprios clientes, podem querer registrar. A gente pode receber dados aqui para poder fazer um filtro, e aqui também. Pronto, então a gente vai acabar pegando aqui no construtor o quê? Um CustomerRepo, para poder fazer a nossa operação. Então, aqui vai entrar o iCustomerRepository. Tem que injetar ele aqui e ele vai ser usado juntamente com o agregado de Customer para que a gente possa orquestrar essas regras que interessam aos stakeholders e etc. Pronto, então, basicamente, a camada de aplicação vai ser esse amaranhado de métodos. Na visão, tanto do Evans quanto do Valgvernon, esses métodos podem ser reutilizáveis, se você precisar. Você vai ver outras abordagens, como lá na Clean Architecture, que também a gente tem uma camada de aplicação que a gente vai trabalhar com conceitos de caso e uso, mas eu não quero entrar isso aqui no momento mas é uma abordagem que é a mesma coisa no sentido conceitual mas tem algumas diferenças mas a gente já fica com esse olhar para saber que é a mesma coisa, porque eu sei que muita gente vai chegar aqui e vai ter a dúvida, mas aqui a gente vai ver nesse módulo, não quero trabalhar com Clean Architecture, a gente vai ver apenas Application Service, mas aí a gente vai ter que criar aqui as nossas regras de negócio. Então, eu queria fazer essa primeira definição para ficar claro que é a aplicação em si que é usada pelo usuário então a gente entra naquele conceito aqui da arquitetura em camadas, o usuário interage diretamente com as entidades, com os agregados, com os repositórios, não, Eu tenho as camadas, eu tenho as regras cruciais que estão ali nas entidades e nos agregados. Então, a aplicação delimita esse limite e expõe uma interface que o usuário, ou que os usuários vão utilizar. Inclusive, eu vou até mudar isso aqui para... Pode ser cliente, no sentido que é um cliente da nossa aplicação. Então, a gente vai montar os application services pertinentes, olhando agora num sentido mais gerencial, o que eu preciso para poder satisfazer as necessidades do usuário e como a gente pode fazer essas operações de forma eficiente, o que é necessário ter. E depois a gente vai até chegar ali num ciclo de vida dessa aplicação, fazer a integração com o Nest e também depois gerenciar os eventos. Então, pessoal, vamos continuando a nossa saga. É isso aí. E até a próxima.