Salve, Deus, beleza? Começando a nossa saga aqui com o Domain Drawing Design, vamos começar refletindo sobre o que nós já vimos aqui no MBA. Wesley ministrou com maestria lá a parte de System Design, criando aqui o Scholar Draw. Nós temos aí os requisitos do sistema, os requisitos funcionais, não funcionais, planos de capacidade, os cenários de comunicação entre os sistemas, até mesmo da limitação de como a gente poderia trabalhar com o envio de e-mails. E uma espécie de modelagem aqui, isso aqui não é nem um diagrama de classes, seria um diagrama de entidade e relacionamento. Está mais para isso. Mas aí vem o questionamento. A gente viu lá as aulas do Vernon. Aonde que entraria a DDD aqui? No começo, no meio e no fim. Aquela pergunta. Quem veio primeiro, o ovo ou a galinha? Eu não sei qual é a resposta. Mas imagino que todo mundo tenha um argumento, mesmo que seja a galinha? Eu não sei qual é a resposta, mas imagino que todo mundo tem o argumento, mesmo que seja a galinha, mesmo que seja o ovo, todo mundo imagina alguma coisa. Então, nesse caso do system design, a gente pode às vezes pensar que o DDD viria depois. Ah não, peraí, o DDD lá tem a parte das entidades, que a gente vai ver daqui a pouco, os agregados, enfim. Então, li na área de implementar o software. E essa seria a resposta mais errada que a gente poderia dar. Porque uma vez que a gente viu ali o que o Vernon disse e também o que está nos livros, DDD, antes de tudo, é comunicação. É linguagem ubíqua. É melhorar a comunicação entre as equipes, entre a hierarquia da empresa, para que todo mundo passe a melhorar a sua própria comunicação, para que eles comecem a falar a mesma língua. E, de fato, a gente consiga captar a essência do software que é o objetivo então antes de tudo nós desenvolvedores sermos menos egocêntricos e inclusive o Evans fala isso no livro azul, porque a gente imagina que os stakeholders os usuários são um conveniente no meio do software. Se o software só tivesse a gente, a gente conseguiria fazer a modelagem perfeita e fazer tudo funcionar. A gente não imagina que nós somos uma parte dessa engrenagem e que você não é o domain expert. É o domain expert que tem as informações mais valiosas. Você, como profissional da tecnologia, é que vai captar essa essência, essas informações que valem ouro, para que elas sejam aplicadas no software. Então, essa visão técnica que muitas vezes você tem porque você quer resolver a bagunça que está no meio do seu software, ela ali é uma questão em nível de código. DDD, a princípio, a gente nem está pensando em código. Então, essa resposta estaria totalmente correta. Mas aí, quando a gente vai para a pergunta do meio, que se ele está aqui no meio do processo do System Design, nós temos os requisitos aqui, até que o plano de capacidade não temos nada bem ligado ao DDD, mas aqui nos cenários de como que a compra de ingresso, de como que a apresentação do QR Code vai acontecer, nós temos aqui um pouco do DDD, porque nós temos os contextos identificados. Eu tenho a compra de ingressos, o gate de pagamento, não está especificado, mas todo usuário vai ter que fazer a autenticação, ele tem que ser identificado, a gente tem que saber se ele é um cliente, se ele é um parceiro, ou até se ele é um administrador. Então, aqui nós temos muitas coisas do DDB, nós temos uma visão do software, mas claro que é um pouco mais técnica, porque aqui a gente já está pensando qual banco de dados, ou pelo menos, vai ser um banco de dados para cada aplicação. Vou usar um message bus para poder trabalhar com o envio das mensagens para o meu serviço de e-mail. Aqui é uma visão muito mais técnica, mas o DDD está aqui. Mas aí que é o ponto. O DDD é uma concepção inicial do software. Eu tenho o domínio do problema, que é o que a empresa faz ou o que esse software tem que fazer. Eu tenho que vender ingressos. Esse é o nosso domínio. Ou eu poderia chamar de ingressos, ou compra e venda de ingressos. Dentro desse domínio, nós temos a identificação das áreas que vão se relacionar para poder resolver esse problema. Às vezes, essas áreas podem ser identificadas como as áreas que a empresa tem ou como uma partição ali do domínio em subproblemas. Então, os domínios são subproblemas a serem resolvidos. Essa visão, a princípio, ela não está pensando se vai ter mensageria, se vai ter banco de dados, se vai usar HTTP, se vai usar Clean Architecture. Não, a gente não está pensando em nada disso. Eu só quero entender o domínio do problema, ver os requisitos desse software. E quando a gente está falando de requisitos, são os requisitos funcionais, que são as regras de negócios, problemas. Uma vez que eu tenho essas áreas, agora eu quero ver como essas áreas vão se relacionar para entender qual é o custo de comunicação entre essas áreas, fazer a separação dos contextos e também da linguagem que vai ser falada em cada um dos contextos e, acima de tudo, determinar nesse subdomínio qual é o núcleo, qual é o domínio principal ali desses subdomínios. Porque é aqui que eu sei que é a parte mais sensível, que eu tenho que errar menos. Essa parte tem que ser estável e é dali, essa parte vale ouro. É dali que a gente vai tirar o nosso valor, o valor do software, onde ele vai se pagar, onde a empresa vai crescer. Então eu vou colocar os desenvolvedores mais valiosos, mais talentosos da minha empresa ali, porque aquilo ali representa um risco muito grande. Aquilo ali tem que ser muito bem modelado. É claro que esse sistema aqui de venda de ingressos é um sistema muito pequeno. Para a gente poder analisar de forma profunda a questão do DDD. O Vernon deixa bem claro nas aulas iniciais e também lá no livro que DDD precisa ser aplicado quando você tem um problema mais complexo. Não que ele não possa ser aplicado aqui nesse tipo de sistema, mas é que quando você tem um problema mais complexo, é muito mais tesão, é muito... explode a sua cabeça ver ali que você vai refinando esse modelo, entendendo que as suas decisões ali lá na frente vão ter um impacto muito grande até mesmo. Elas vão te dar uma visão no system design como que você vai estabelecer as coisas. Então, DDD, acima de tudo, está lá na concepção do software. Mas como ele está aqui no System Design, ele está na comunicação o tempo inteiro que a gente está fazendo entre as equipes, entre as pessoas, os participantes do sistema, ele está lá no meio do código, o DDD está em todo lugar. Porque a todo momento a gente está mexendo com o coração do software. Ele vai estar lá também no meio do seu desenvolvimento. Porque você vai pegar os termos, os conceitos, tudo que está sendo falado e jogando no meio do código. Então o DDD, de forma boa, ele contamina... Ele contamina todo o processo de desenvolvimento. Apesar dele ser feito principalmente lá no início. Então, essa reflexão aqui é muito importante. Show de bola, pessoal. Então, vamos continuando aqui a nossa saga. É isso aí. E até a próxima.