Salve Deus, beleza? Continuar nossa saga aqui no Domain Dreaming Design Agora vamos falar sobre essa visão Que provavelmente você já deve ter ouvido Você quer trabalhar com microserviços? Utilize o DDD porque ele vai te ajudar A identificar os microserviços Que precisam ser construídos. E isso é uma verdade, a gente vai entender o porquê aqui nessa aula. Dado o nosso domínio e subdomínios que estão lá na nossa solução do problema, nós idealizamos dessa forma aqui, essa aqui poderia ser uma visão mais assertiva da divisão entre as aplicações. Porque aqui nós estamos pensando em uma solução de negócio que vão ter os seus devidos contextos, ou seja, nós vamos ter coisas mais agrupadas que se modificam mais em conjunto, permitindo um maior desacoplamento. É porque eu tenho a questão lá de geração do ingresso, desacoplada aqui dos eventos. Então, permite ali que eu lide com esse problema que é gerar QR Code e outras coisas de forma independente lá dos eventos. Inclusive, essas aplicações, no final das contas, elas vão ser escaladas de uma forma totalmente diferente. Imagina uma situação que isso aqui estivesse dentro de um mesmo domínio e eu tivesse que escalar toda a minha aplicação de eventos só por conta dos ingressos. Seria uma decisão que não estaria necessariamente errada, mas ela pode ser um gasto desnecessário. Então, quando eu tenho um contexto, eu tenho algo agrupado, algo coeso que está junto. Algo que nós idealizamos que é um problema que tem que ser resolvido ali. E aí eu vou criando os outros contextos que vão se relacionar. Então, como eu tenho algo coeso que não tem um acoplamento zero, a gente quer que esse acoplamento aconteça, o Wesley já falou disso aqui no curso, não existe isso, a gente quer que de alguma forma tenha um acoplamento, mas como a gente idealiza esses contextos, separa muito bem esses problemas, é um bom indicativo disso aqui acabar virando um número de microserviços. Mas, como nós vamos refinando o modelo, entendendo mais as regras de negócio, não pense que isso aqui é a decisão certa a se tomar, é a decisão que a gente conseguiu baseado no que nós conseguimos extrair dos domain experts, pode ser que daqui para frente o espaço da solução... A gente pode querer juntar ingresso com eventos ou eu posso gerar outros subdomínios para poder separar mais a solução de um outro problema. Então, como esses contextos separam de um outro ambiente, que é a ideia de microserviços, eu quero que tenha um serviço que esconda os detalhes de implementação, que seja reusável ali no meu processo de negócio, o DDD é uma boa metodologia para nos dar essa visão. Então, muitas vezes você pode usar o DDD para poder fazer a especificação do problema, da solução, mas na prática ali, no meio do código em si, não precisaria necessariamente ter os agregados, as entidades e etc. Só da gente fazer a nossa modelagem estratégica, já seria interessante para poder entender os contextos e o que poderia ser microserviços e as consequências dessa decisão aqui. Porque baseado na relação entre essas aplicações, a gente pode ver que às vezes não faz sentido você ter algum subdomínio, faz sentido ter mais subdomínios ou como que seria a relação entre eles para às vezes você tomar até uma decisão de que a comunicação entre essas aplicações faria mais sentido ser assíncrona ou síncrona, dependendo do contexto. Então, o DDD é uma metodologia de modelagem muito importante para a gente poder trabalhar com microserviços. Maravilha, pessoal. Então, vamos evoluindo aqui na nossa saga. É isso aí. E até a próxima.