Salve Deus, beleza? Continuamos essa saga aqui no Domain Dreaming Design. No último capítulo, nós tivemos uma visão sobre a estratégia de criar o software e também de encontrar quais são os subdomínios core do meu sistema. Porque nesses subdomínios core que nós vamos ter mais investimento, onde os desenvolvedores mais talentosos vão estar alocados. E, obviamente, o maior risco desse software não dar certo ou se aquele core domain não funcionar, eu tenho um grande risco de perder muito dinheiro com esse software. Então, dado o nosso exemplo de venda de ingresso, que nós temos aqui os cores que são os eventos e o próprio ingresso, a autenticação como sendo um subdomínio genérico, que a gente poderia usar qualquer coisa para poder prover a autenticação, e o de e-mail também, que poderia ser de suporte ou genérico, que eu falei também sobre esse caso, porque ele acaba sendo uma mistura dos dois, porque a gente tem que construir um sistema, mas um sistema de terceiro vai acabar sendo o alvo para poder fazer o envio de e-mails. Então, a gente acaba colocando aqui como genérico. Muitas vezes, os dois termos acabam colidindo. O suporte normalmente é usado ali quando a gente tem aqui um subdomínio que vai dar suporte para o evento funcionar, alguma coisa que não seria necessariamente o core aqui do nosso projeto. Então, essa é a visão estratégica, essa visão do problema que nós temos para poder resolver. Mas não basta só ter a visão do problema, nós precisamos ter a visão de como esse problema vai ser resolvido. E é aí que entra o design tático. Então, uma vez que a gente já fez toda essa modelagem, agora vai vir a parte que muita gente gosta, porque a gente consegue aplicar isso, ver isso, ver a teoria sendo aplicada ali no meio do código. Então, na tática, nós vamos solucionar esse problema, dado os subdomínios existentes, não só os cores, mas os genéricos e os subdomínios, como que nós vamos resolver aquele contexto delimitado? Então, vai envolver criarmos entidades. E todo mundo quer ver entidade, a gente vai falar mais disso daqui a pouco. E, na verdade, a nossa visão de entidade normalmente é muito poluída por ORMs. Objetos de valores é muito subestimado. Inclusive, eu nem tinha acrescentado aqui. Antes de começar a aula, eu olhei para cá e falei assim, mas espera aí, cadê o objeto de valor? Faz parte aqui também. Então, vamos ter os objetos de valores para poder modelar os valores das entidades, os agregados, que são entidades também, mas tem um comportamento mais complexo, repositórios, serviços de domínio, módulos, eventos de domínio. Nós podemos acrescentar mais coisas aqui, inclusiveódulos, eventos de domínio. Nós podemos acrescentar mais coisas aqui, inclusive até factories, até outros design patterns. Tem um design pattern que é muito abordado nos dois livros, que é o specification, que resolve vários problemas também da nossa modelagem de domínio, como validação de dados, processamentos diferentes, dependendo de uma perspectiva. Então, é como que eu vou pegar esse subdomínio e resolver essa solução. Então, esses aqui são os artefatos do design tático. A gente consegue pegar esses artefatos e aplicá-los lá no meio do nosso código. Mas o que precisa ficar claro em relação ao DDD é que a gente pode ficar apenas no estratégico, dependendo até ter uma visão do tático e não ter uma implementação purista no meio do código. Não tem problema. De qualquer forma, o DDD vai agregar valor. Mas uma vez que a gente consegue fazer esse design tático no meio do código, o que vai acontecer é que nós vamos ter documentos, nós vamos ter linguagem ubíqua falando também a mesma linguagem do software. Então, quando o desenvolvedor vai ver o código fonte, ele vai ver todos os conceitos tudo transparente lá no projeto. Isso torna o nosso projeto, tende a tornar muito melhor. E uma frase que o Evans fala no livro Azul, eu acho muito legal, eu guardo sempre essa frase e falo nas aulas. O código é o projeto e o projeto é o código. Então, de certa forma, não adianta nada você fazer o design tático e você não respeitar os conceitos que foram estabelecidos aqui e aplicar outra coisa no meio do software. O software tem que transcrever essa linguagem ubiqua. Ele faz parte desse contexto todo. Nós vamos ter uma parte prática em que isso vai ficar muito claro. A gente vai ter marcação bem clara. Ah, isso aqui é uma entidade, isso aqui é um objeto de valor, isso aqui é um agregado. Toda essa linguagem é transferida para o meio do software. Então, nesse capítulo, nós vamos ver cada um desses pontinhos e falar algumas outras coisas de padrões que seriam interessantes para poder trabalhar com esse design prático, pessoal. Melhor, prático e tático. Então, é isso aí. E até a próxima.