Olá pessoal tudo bem? Sejam todos muito bem vindos a mais uma aula e na aula de hoje a gente vai dar uma pincelada bem rápida sobre os DDD Patterns, os padrões de DDD, principalmente da modelagem tática que a gente já andou utilizando e a gente vai revisar novamente o que a gente utilizou e revisar cada um deles. Então, vamos lá. Valley Objects. A gente utilizou o Valley Objects dentro do nosso objeto de Name, da nossa classe Name, da nossa classe CPF, CNPJ. Os Valley Objects são objetos cujo a sua identificação é através dos seus valores. Um CNPJ, por exemplo. O CNPJ, a sua identificação, a sua condição igualitária é através do seu valor, que é o número do CNPJ. Um endereço, por exemplo. O endereço não faz sentido ter um ID, porque ele não muda. O que diz se um endereço é o mesmo que o outro não é um identificador, e sim os seus atributos. A rua é a mesma, o número é o mesmo, o complemento é o mesmo, são tudo objetos de valor. Entidades. As entidades, em contrapartida do objeto de valor, esse sim, sua característica, sua condição igualitária, é através do ID, um ID único. E os seus atributos podem ser alterados, modificados conforme as regras de negócio, mas o seu identificador sempre vai permanecer o mesmo depois de criado. Então, a gente viu o Customer. O Customer, quando ele é criado, a gente associa um identificador a ele e aí pode ser que esse cliente mude de nome, mude de documento, pode mudar os outros atributos, não vai fazer diferença, ele vai continuar sendo quem ele é, identificado através do seu identificador. Se, por exemplo, uma pessoa no âmbito de um governo é identificada através de um CPF, essa pessoa, por exemplo, ela deve ser uma entidade, óbvio. E a chave primária lá é o seu CPF, por exemplo. Entre outros métodos que nunca é interessante utilizar esse tipo de coisa para mapear chaves de primárias. Mas, enfim, valeu para entender. Agregado. O aggregate. O agregado, na verdade, ele é o termo que faz referência a uma entidade que faz referência a justamente uma entidade que faz referência a justamente uma entidade que é um cluster, na verdade, de objetos e classes, que tem muitos, que tem N entidades, objetos de valor dentro dela, e ela representa o limite transacional entre todas essas classes de objetos de valor. Ou seja, o agregado é o conjunto de entidades e objetos de valor que representam algo no nosso domínio que precisam ser persistidos juntos atomicamente. Esse é o conceito do agregado. Além do conceito do agregado, a gente tem o conceito do aggregate hood, a raiz de agregação, que essa sim é a classe, propriamente dita, daquele agregado que expõe, inclusive, os métodos públicos que manipulam o comportamento dela e que traz a regra de negócio, que dá valor ao modelo de domínio da nossa aplicação. Essa classe a gente chama de Aggregate Hood. Toda Aggregate Hood é uma entidade. Ela tem um identificador. Mas nem toda entidade é um Aggregate Hood. E por último, a gente tem os Domain Events. Então, os Domain Events, que a gente chama de eventos de domínio, a gente vai ver na próxima aula com mais carinho sobre eles, sobre principalmente como utilizar eventos ali dentro do CleanArch. Mas os eventos de domínio são eventos gerados a partir de mutações, quando você tenta manipular um agregado. Esse agregado pode produzir um evento de domínio e esse evento vai ser propagado para outros sistemas outros pacotes, para que você notifique e consiga interagir com outros agregados e com outros casos de uso da sua aplicação a partir do seu agregado sem gerar um acoplamento e claro, tudo isso com consistência eventual então é isso, recapitulamos rapidamente um pouquinho aqui dos DDD Patterns, mais da modelagem tática do DDD. E aí na próxima aula eu vou explicar um pouquinho mais sobre os domain events, porque é importante a gente entender sobre como que a gente vai lidar com eles, como a gente produz eles e como a gente vai integrar com eles dentro da nossa arquitetura limpa, da implementação do CleanArt lá no Subscribe Customer to Event.