Salve, beleza? Continuamos essa saga aqui no Domain do Rendesign. Agora vamos falar sobre aquela questão, mais uma vez, do código é o projeto, o projeto é o código. A gente deve pegar ao máximo os termos, a linguagem ubíqua e transferir aqui para o meio do nosso projeto, porque isso vai melhorar a nossa comunicação, o entendimento do projeto, o refinamento dele, tende a ser feito com muito mais qualidade. Então, quando a gente olha aqui para esse customer, imagina que uma nova pessoa está chegando no seu time. Obviamente, você vai ter algum documento ali, falando, olha, eu tenho esses agregados aqui, etc. Mas no dia a dia, às vezes até você que criou esse código, passou um tempo, você não lembra mais quem é agregado e quem é entidade. E essa distinção é importante, porque a gente sabe que o agregado é o protetor das regras de negócio. E uma entidade está sendo utilizada por um agregado. Então, a marcação das classes é essencial. Então, o que eu gosto de fazer aqui nos meus projetos é o seguinte. A gente vai criar aqui duas pastinhas. Então, eu vou ter a pastinha de common, que vão ser coisas comuns, que a gente vai acabar fazendo para todo o nosso projeto aqui de DDD. Então, dentro também desse common, nós vamos ter um domain, um application, e uma infra. Vou trabalhar sempre com esse conceito para poder fazer essa distinção. Aí essa parte que a gente está criando é sobre qual domínio? Eventos, né? A gente tem isso lá no Scaled Draw, em Event Storming. Então, eu não gosto muito de usar a palavra eventos, porque evento é uma palavra tão genérica. Você tem ela dentro do framework, dentro do seu ORM. Então, essa pastinha aqui é para se referir ao conceito do evento, que é o nosso produto que a gente está vendendo. Então, vamos copiar aqui a pasta application para cá, a pasta infra também para cá e a pasta domain para cá também. Então, a gente só fica aqui com esses dois níveis. Aí aqui dentro de domain eu posso criar o meu entity.ts Então vou ter o export class entity Pensando que essa classe aqui ela nunca vai ser instanciada diretamente ela pode ser abstrata Toda entidade vai herdar de entity ela nunca vai ser instanciada diretamente, ela pode ser abstrata. Todo mundo vai... Toda entidade vai herdar de entity. E aqui nós podemos colocar comportamentos comuns, comportamentos que vão tunar ali as nossas entidades. A princípio, o que a gente tem de comum que teria em todas as outras entidades? O 2JSON. Então, vamos criar aqui um abstract, toJSON, que vai devolver qualquer coisa, eu não quero delimitar nada, cada entidade que define o seu. Então, agora, eu vou chegar aqui e vou falar que eu sou uma entidade. Aí o TypeScript vai chiar comigo, porque, como eu estou herdando, você vai fazer lá como no Java, né? Tem que fazer um... chamar o construtor da classe Python, o super aqui. Não tem nenhum parâmetro para passar? Pronto. Então, agora, quando eu olho para isso aqui, eu sei que ela é uma entidade. Porém, Customer não é uma entidade. Customer é um agregado. Ele é a raiz do agregado. Então, a gente vai criar também aqui um aggregate-root. traço root. Estou chamando esse nome para representar justamente, porque agregado também é outro nome que é usado em frameworks e tecnologia. Às vezes, você pode encontrar alguma coisa aqui que é agregado, pode confundir, agregado de eventos e tal. Então, esse aggregate root é um nome bem usado pela comunidade, bem interessante para a gente poder trabalhar. O agregado, no final das contas, ele é uma entidade também. A raiz do agregado, ele é uma entidade. Então, eu posso fazer ele herdar de entity. Aí aqui vai fazer com que ele implemente o 2JSON se ele não for abstrato, então eu vou forçar que ele seja abstrato, porque eu não preciso instanciá-lo, chego aqui no meu Customer e coloco o AmpliGate root, beleza. Então vai forçar ele a fazer o 2JSON, e agora eu tenho essa marcação aqui, então a gente vai acabar utilizando essa marcação sempre para as nossas coisas. Nem que não seja uma classe, mas seja uma interface para, de fato, o projeto ser o código, o código ser o projeto. Quando a gente olha as terminologias, a linguagem ubíqua, essa linguagem está transcrita também no meio da nossa programação. E aquela história que eu estava falando, se eu não quiser trabalhar dessa forma, tem algum problema? Não, não tem problema. Se o seu projeto é um pouco menor, não precisa trabalhar dessa forma aqui. Você pode ser mais flexível ou até mesmo começar a utilizar tecnologias ou bibliotecas. A escolha é sua. Às vezes, por algum motivo, uma decisão de arquitetura, você vai trabalhar dessa forma para ser mais direto. Mas essa forma que nós estamos trabalhando aqui é a forma pura de tentar ao máximo livrar esse nosso core de tecnologia. Até o momento aqui a gente não tem nada de bibliotecas e etc. Nem de Node ainda assim tem aqui. A gente está trabalhando apenas com o próprio TypeScript para poder formar o coração do nosso software então sempre faça marcações para que a comunicação do seu código seja melhor vamos continuar nossa saga, é isso aí e até a próxima