Salve Deus, beleza? Continua nossa saga no Domain Dreaming Design. Agora nós vamos falar sobre duas perspectivas. Em nenhum momento isso é algo que você tem que seguir, mas é justamente uma visão que é interessante ter em cima do Domain Dreaming Design, que é o espaço do problema versus o espaço da solução. Esses nomes estão bem claros. Enquanto no espaço do problema nós vamos enxergar o problema, enquanto na solução é como que nós vamos resolver esse problema. E o que é o estabelecimento do domínio do software? É justamente o problema. Então, no espaço do problema, inclusive, deixa eu até falar antes, que essa perspectiva de visão da modelagem, ela é bem mais especificada pelo Vernon no livro Red Book do que no do Evans. O Vernon fala que o espaço do problema é justamente identificar qual é o domínio principal, acho que ninguém tem dúvida que é o nosso vendas, compra de ingresso, e as áreas, os subdomínios, que vão estar dentro do nosso domínio, ou seja, aqueles subproblemas que têm que ser resolvidos, que o nosso software tem que conceber. Então, no espaço do problema, eu posso às vezes a gente pensa assim, estou concebendo aqui o software, a gente vai delimitando aqui as áreas, mas às vezes você já tem alguma área pronta que pode ser reaproveitada dentro da sua empresa. Então, nesse espaço do problema, é identificar novos subdomínios ou subdomínios existentes também. Acaba que na visão do DDD, um subdomínio, mesmo que ele seja identificado, vamos dizer, domínio de autenticação seja identificado aqui e em outros softwares que têm que ser desenvolvidos, mesmo que ele seja um software genérico que vai ser agregado, mas o subdomínio é diferente de um outro, mesmo que eles tenham o mesmo nome, mesmo que seja uma solução que é a mesma. Porque dentro desse problema de venda de ingressos, lembre-se que o subdomínio vai ter o seu contexto, a sua linguagem ubíqua. Então, mesmo subdomínios que parecem que são iguais em vários softwares diferentes, eles são diferentes por conta justamente do contexto. Então, nós estabelecemos aqui nesse espaço do programa de venda de ingressos um subdomínio de eventos. Esse subdomínio vai ter a parte dos parceiros, tudo que envolve o evento. Os parceiros, o cliente, o próprio evento em si, que é o acontecimento que vai ter na data-hora, os assentos. A parte do ingresso, que é justamente aquela parte de determinar os QR Codes e também fazer a validação de ingresso, tanto de participantes do sistema, tanto pelo próprio cliente. Tem a parte de autenticação, claro, porque eu preciso estabelecer ali a identidade do usuário para poder ver o que cada um pode fazer, o que cada um está autorizado a fazer, e também a parte dos e-mails. cada um está autorizado a fazer e também a parte dos e-mails. Então, esse aqui é o nosso problema para poder vender o software. A gente vai estabelecer ali o que cada subdomínio vai fazer, conversando exatamente sobre os requisitos. Então, aqui está o nosso problema. Aqui eu não estou pensando em relacionamento entre subdomínios, entre contexto. Aí que vai entrar o espaço da solução. Então, no espaço da solução, nós vamos pegar esses subdomínios estabelecidos no espaço do problema e ver como que eles vão ser solucionados. Ah, então esse nosso evento aqui é um core. Isso aqui é importante também, porque aqui já a gente pode determinar o que é mais importante, quais seriam os core domains, o núcleo, o domínio que vale ouro aqui para o nosso software? A parte de eventos e a parte de ingresso. Eu acho que dificilmente alguém vai discordar dessa parte. Ah, mas dois subdomínios podem fazer parte do core? Sim, eu posso ter essa separação, porque eu quero ter essa visão que eu tenho as duas soluções que estão sendo separadas. Porque, no final das contas, o ingresso em si é a gente conseguir gerar esse documento e eu não preciso necessariamente do evento. Eu posso gerar esses documentos e aí vai ser o meu subdomínio de eventos que vai fazer a utilização disso. Por isso que nós temos uma relação de upstream e downstream, cliente-fornecedor, porque pensando no nível da nossa empresa, esses dois domínios, a gente tem equipes menores, a nossa organização não tem tantos desenvolvedores assim. Então, tanto um e outro, que eles precisarem de alguma coisa, eles vão estar prestes, dispostos ali a resolver os problemas uns dos outros. Se o evento precisar de alguma coisa aqui de ingresso, a equipe, sim, vai avaliar porque vai ser importante. Ainda mais porque a gente está no core domain. Então, onde a gente vai gastar mais grana, onde a gente vai mais investir, é aqui nesse eixo. E no caso de downstream e upstream, fica claro que eventos é um consumidor de ingresso. Então, o ingresso é o fornecedor e eventos é o cliente. Por isso que ele é down, ele está fazendo o download. É sempre bom fazer essa analogia para não ficar confuso. E o ingresso está fazendo o upload. No caso da autenticação, vamos pensar o seguinte. Poxa, vale a pena eu desenvolver a minha autenticação e tudo mais? A gente já poderia, sei lá, usar alguma coisa pronta. Pode até ser algum framework, alguma coisa assim que resolva o meu problema, até um software de terceiro. Então, nesse caso, é um domínio genérico. Normalmente, quando a gente quer ver esse subdomínio que é de apoio, ou principalmente genérico, são softwares de prateleira que a gente pode adquirir, que vai valer muito mais a pena do que você ficar desenvolvendo isso, de eu colocar desenvolvedor para trabalhar nisso. Eu pego alguma solução e agrego aqui. Então também nós temos essa relação de upstream e downstream conformista. Porque uma vez que eu vou preferir agregar um software aqui e tem trocentas softwares no mercado, o pessoal lá que fizer o software não vai fazer modificações porque o meu evento está precisando. Vocês concordam? Então, eu tenho que me conformar, eu aqui como um downstream, eu tenho que me conformar em usar a autenticação do jeito que ela é. Eu tenho que tanto me conformar com as vantagens e desvantagens disso. E a parte de e-mails? Também eu sou um downstream, porque a gente está usando, eu sou um cliente, o e-mail é um fornecedor. Veja que eu não tenho nenhuma visão. Ah, se eu vou trabalhar com mensageria e tal, isso foi estabelecido lá na frente com o system design, mas eu sei que eu tenho um cliente fornecedor aqui, essa solução também poderia ser genérica, mas acaba que a gente poderia criar ali uma solução que trabalha com um terceiro de envio de e-mails. Essa solução vai pegar ali os e-mails a serem enviados, comunica lá com XPTO, ABC e faz o envio. Então, essa visão aqui de solução, talvez a gente subestime, mas olha como ela é importante, porque ela está nos dando uma visão que o Eventos, que é um dos cores, ele sempre está tendo relação downstream. Então, quando a gente tem aqui essa relação downstream, existe um risco que os upstreams mudem, impactem eventos. A gente já tem que ter isso logo de cara. Então, depois nós vamos ter que pensar mecanismos de fazer com que esse domínio fique protegido, principalmente desses dois aqui, e também que ingressos não façam esse domínio ficar instável demais. Porque sempre quando eu tenho uma relação downstream, sim, esse cara acaba se modificando muitas vezes porque os outros ups foram modificados. E como ele é um core, ele tem que ser o mais estável possível. Porque quanto mais estável, eu tenho um custo menor de manutenção, mais estável possível. Porque quanto mais estável, quanto mais estável eu tenho um custo menor de manutenção, eu tenho menos bugs, eu consigo gerar mais valor. A gente não está falando nada aqui de linguagem de programação e nada disso. É apenas uma visão do software. Então, só o mapeamento de contexto aqui na nossa solução, nós já conseguimos discutir se isso aqui faz sentido ou se a gente tem que se relacionar com os contextos de alguma outra forma. Enfim, o exemplo é muito simples também para que a gente possa ficar divagando aqui ou refletindo demais. Mas a solução é justamente pegar os subdomínios e estabelecer a relação entre eles e depois claro, a gente vai lá pra parte tática, mas a parte tática a gente vai abordar depois, mas a solução é justamente essa perspectiva do problema que a gente tem aqui em cima futebola pessoal, então vamos continuar a nossa saga, é isso aí e até a próxima