Olá pessoal, sejam todos muito bem-vindos a mais uma aula e na aula de hoje eu vou comentar um pouquinho sobre os tabus e as dúvidas que as pessoas têm sobre as entidades e as formas como elas relativizam o conceito de entidade e eu vou explicar como é importante que a gente trabalhe com um domain model, com um modelo de domínio rico na nossa publicação. Então, vamos lá. Entidades e a sua relativização. Primeiro que a gente precisa entender é o conceito do modelo anêmico. modelo anêmico. Este termo vem principalmente em linguagens orientadas a objetos. E o modelo anêmico são basicamente aquelas classes que não possuem comportamento algum e não encapsulam absolutamente nada. E são um bando de estruturas de dados puras, simples. O que quer dizer isso, então? No modelo anêmico, você tem classes cujo são apenas estruturas de dados, e que todos os comportamentos foram vazados para outros lugares, como, por exemplo, services, controllers, DAOs. Então, a classe não sabe se validar, a classe não sabe fazer outras coisas que a não ser sets e getters. Então, esse é o modelo anêmico, e a gente deseja sempre fugir do modelo anêmico, por isso que a gente implementa um domain model, que é um conceito de modelo de domínio rico, onde a gente tem classes que encapsulam os comportamentos delas para você manipular os seus atributos, somente através desses métodos que possuem comportamentos, que possuem validações, e esses métodos não estão em outros lugares, como casos de uso ou services, a não ser que seja de fato pertinente estar lá. Isso significa que a gente não vai ter o modelo anêmico na nossa aplicação? Não. Na verdade, a gente vai ter principalmente nas entidades JPA. Na camada de persistência, esses objetos relacionais, normalmente eles são muito anêmicos. São um bando de getters e setters mesmo, só escutadores de dados, para que a biblioteca, o framework, interprete e consiga enviar para o banco de dados, a persistência. Relacionamento entre entidades. Esse é um assunto que tem uma abrangência muito boa. Por quê? Porque ele vai variar dependendo se a gente estiver usando o DDD ou não. se a gente estiver usando DDD ou não. Mas dá para a gente pensar em algumas regrinhas aqui que fazem sentido em quase todos os casos, os cenários. Então, vamos lá. O relacionamento de entidade para entidade, sendo essa entidade um agregado, então aqui falando um pouquinho sobre ele já, DDD, se essa entidade é um agregado, ela é uma raiz de agregação, um agregado só deveria ser vinculado a um outro agregado através do seu ID. Então, relacionamento através de ID entre agregados. Então, relacionamento através de ID entre agregados. Agora, uma raiz de agregação que tem uma entidade nela, essa entidade não é uma outra raiz de agregação, ela só é uma entidade mesmo, ela só é um objeto cuja sua característica, cuja sua identidade através do seu ID, esse sim pode ser relacionado por inteiro no agregado. Então, o agregado pode ter dentro dele uma entidade. Então, vamos supor, carro tem uma entidade pneu, porque o pneu é único, tem a data de fabricação, tem o modelo, tem o código. Então, aí está tudo bem o carro ter o pneu. Agora o carro, ele não tem, por exemplo, um motor, porque o motor é um agregado bastante complexo, com milhares de peças, que precisa ter outras entidades, então cada um são agregados, mas o motor referencia um identificador que o carro referencia ou o ID do agregado motor. Então, essa é a principal diferença. Se a gente estiver falando agora de entidades do JPA, por exemplo, aí sim você vai precisar ter entidades acopladas, justamente para você poder navegar entre elas, entre os relacionamentos do seu objeto relacional. Não tem muito como fugir. Mas, em via de regra, sempre tente trabalhar com entidades ou agregados que apenas conhecem os identificadores de outras entidades. E a justificativa, a razão para isso é porque você tem que pensar também apesar de você estar no seu caso de uso e apesar de você estar no seu comédico domínio não podemos ser ingênuos e esquecer da forma como esses caras são persistidos e recuperados então se você tiver aqueles como o Van Vernon chama de God Classes de agregados deuses super gigantes, você vai ter um grande problema para persistir esse cara, você vai ter um grande problema com concorrência então eu estou duas pessoas estão manipulando os mesmos os mesmos atributos de algumas entidades e o fato de ser o mesmo agregado pode gerar uma grande concorrência entre eles, um problema de concorrência. Então, isso tudo precisa ser levado em conta na hora de definir como você vai fazer o relacionamento entre as entidades. Posso utilizar libs externas no meu domênio? E a resposta é depende. Lembra que eu falei para vocês que eu faço vista grossa para algumas bibliotecas, como Lombok, como AVR, que são carências da linguagem, a linguagem carece de construções, e aí, em prol da produtividade, a gente faz vista grossa para o acoplamento dessas Vibs. Mas tem que tomar muito cuidado. Nada, por exemplo, de colocar outras Vibs que fragilizam muito o sistema, como String Útils, como Apache Útils. Todos esses caras esses caras têm que tomar muito cuidado, Apache Commons, porque esses sim adicionam fragilidades ao sistema, porque possuem um nível de release, de publicação muito maior, pode ser que aconteça algum bug, tem algum nível de vulnerabilidade, então tem que tomar bastante cuidado com isso. Entidades de domínio e entidades JPA. É importante ressaltar que numa arquitetura hexagonal e numa clean architecture, estamos falando de um domain model, de um modelo de domínio rico, que não tem nada a ver com um modelo JPA. Por quê? Porque Clean Architecture e Slugger Architecture são domain-centric architectures, são arquiteturas voltadas ao domínio. todas anotadas com anotações de JPA, anotações de entidade de qualquer ORM, de qualquer biblioteca, objeto relacional, significa que você está dando valor, você está dando prioridade para a forma como é persistido e você está trazendo as características da persistência para o domínio da sua aplicação. É uma coisa totalmente diferente que a gente busca aqui dentro do CleanArc e dentro do PortionAdapters. Então por isso a gente tem que manter esses dois caras bem isolados. Até onde usar DTOs e Data Structures? Então, a gente vai usar DTOs, que são Data Structures, que são modelos anêmicos, modelos anêmicos não só são entidades de JPA, os DTOs também são modelos anêmicos. A gente vai usar em todos os lugares que não a entrada e a saída do caso de uso. E que não, por exemplo, no nosso domínio. O que for regra de negócio, caso de uso e domínio, são entidades de domínio. Fora isso, são DTOs. A entrada e a saída do caso de uso, acho que na verdade estou fazendo uma correção se eu falei isso ou contrário, a entrada e a saída do caso de uso, sim, são DTOs, são os visores de dados. Eu acho que eu falei isso na exceção aos entradas e saídas, mas o caso de uso para dentro é modelo de domínio. Entrada e saída de casos de uso é DTO, entrada e saída de presenters, de controllers, tudo DTO, que são modelos anêmicos, que são modelos mais enxutos, que no mundo Java agora a gente usa record classes para eles, preferencialmente mutáveis, então a gente vai usar DTO em todos esses caras. É isso? Bom, é isso, falamos um pouquinho sobre as entidades, tiramos algumas dúvidas que muita gente tem, se sobrou alguma dúvida, por favor, não hesite em mandar. Espero que vocês tenham gostado, vejo vocês então na próxima aula.