Bom pessoal, da mesma forma que a gente pode trabalhar com Active Record, a gente tem outras opções para conseguir trabalhar. Uma dessas opções é chamada de Data Mapper. Agora, um ponto que eu quero que você entenda claramente aqui. Quando a gente está falando aqui de Data Mapper, a gente está falando ainda de lógica que vai estar fazendo parte do seu domínio. Quando a gente fala em data table gateway, em row table, row gateway, a gente está falando de gateway, de caras da porta para fora. A gente está falando de data mapper dos caras para dentro ou seja qualquer idéia eu tenho meu domínio complexo mapeado aí no meio do caminho antes do banco de dados eu crio uma interface uma abstração que vai fazer com que eu falho com o banco de dados. Então, se você olhar aqui, olha só que interessante. O DEPAMapper é uma camada de mapeamento que move os dados entre os objetos de bancos de dados enquanto os mantém independentes um do outro. O que significa aqui, galera? Aqui, em person, se você olhar, nós temos o nosso domínio complexo. Eu posso ter diversas classes, diversos relacionamentos e tudo acontecendo aqui. Aqui eu tenho minha lógica de negócio. Aqui no banco de dados eu tenho minhas tabelas de bancos de dados. E pra o meu domínio complexo falar com o meu banco de dados eu coloco um cara aqui no meio que eu chamo de data mapper e esse data mapper toda vez que eu vou inserir alguma coisa alterar fazer consultas ele acesso o banco converte esses dados no padrão que eu preciso e depois né a faz uma hidratação aqui desses dados nas minhas entidades dos meus domínios que são ricos aqui para eu conseguir trabalhar tá então vamos lá vamos entender um pouco mais a fundo olha só quando que você deve utilizar data map domínio complexo porque porque aí nesse caso o domínio complexo ele cresce 100% independente do seu banco de dados e o cara que vai fazer com que o seu domínio complexo fale com o banco é exatamente essa abstração do data mapper. Então, isso aí é um ponto importantíssimo para você se ligar. Outro ponto importante, o seu data mapper, pelo fato dele ser uma camada entre o seu modelo de domínio e o seu banco de dados, ele é acoplado ao banco e ele é acoplado ao seu domínio. Então isso significa que se eu mudar a modelagem do meu domínio, eu não necessariamente tenho que mudar o banco, mas se eu mudar o banco, eu não necessariamente tenho que mudar o meu domínio, porque quem cuida desse meu meio de campo é o Data Mapper. Eu não sei se você está conseguindo perceber a diferença entre o Data Mapper e o banco de dados, e o Active Record, porque o Active Record, a sua entidade de lógica de domínio, ela está colada diretamente no banco. Sua entidade, ela estende o Active Record então ela tem a responsabilidade de acessar o banco mas ela também pode ter responsabilidade de domínio com o data Mapper isso não ocorre porque o seu domínio é uma coisa o seu data Mapper apenas faz intermediação e o seu banco de dados é outra coisa tá há um ponto importante aqui que eu sempre vou deixar claro também tá que muita gente faz principalmente quando está trabalhando com hibernate quanto com um por exemplo diversos rms que adotam esse padrão tá a doc trim para php e etc e. O que normalmente esses ORMs costumam fazer? O ORM, por padrão, faz mapeamento de entidades com banco de dados, que no final do dia é o Data Mapper. Mas o que acontece? Lembra que eu falei para você que a baita desvantagem do Active Record é exatamente ter a lógica de domínio dentro da sua classe do Active Record? Pois é. Muita gente cria a entidade, por exemplo, pessoa, e faz o mapeamento através de annotations, não interessa a forma como ele faz, do Data Mapper para falar com o banco de dados. E a lógica de domínio está nessa entidade. não interessa a forma como ele faz, do Data Mapper para falar com o banco de dados. E a lógica de domínio está nessa entidade. Então, o que isso significa, galera? Significa que, se for para você trabalhar desse jeito, é melhor você utilizar Active Record. O Data Mapper separa o seu modelo de domínio da abstração do seu banco de dados. Então, muita gente quer aproveitar essa entidade de mapper para utilizar essa entidade como domínio. Então, o que ele faz? Ele tem uma entidade pessoa, que tem nome, sobrenome, RG, CPF. Ele faz o mapeamento dessas colunas com o banco de dados e utiliza essa entidade para trabalhar com o banco de dados e utiliza essa entidade para trabalhar com o seu modelo de domínio. Isso é o pior dos mundos, porque você tem a complexidade do Data Mapper e não tem os recursos do Active Record. Então, sempre a minha dica quando você for utilizar Data Mapper é crie a modelagem de domínio e crie a sua entidade do data mapper. Então, se você tem, por exemplo, uma classe pessoa, você vai ter uma classe pessoa entidade de domínio e você vai ter uma outra classe pessoa para mapeamento do data mapper. para mapeamento do Data Mapper. Eu da mapeamento do Data Mapper, o que ele vai fazer? Ele pode receber dado de domínio, fazer essa conversão e jogar para o banco de dados. Mas nunca misture a sua entidade de domínio com a sua entidade do Data Mapper. Isso que eu quero trazer aqui para você. Então, outro ponto importante, você vai perceber que muita gente que faz essa mistura né de entidade de domínio de entidade com map e coloca tudo uma coisa só pra evitar que a lógica do domínio vaze para o banco de dados acaba fazendo o que não colocando lógica nenhuma dentro da entidade e isso significa o que que você começa a ter entidades anêmicas e o que? Não colocando lógica nenhuma dentro da entidade. E isso significa o que? Que você começa a ter entidades anêmicas. E o que que isso significa? Significa que você vai ter uma entidade somente com GetSet. E que não resolve o problema de domínio. E aí o que que você faz? Você cria os tals dos services que tem toda a lógica de domínio. Então no final do dia você vai ter entidades anêmicas que, no final do dia, só está falando com banco de dados. Então, nesse caso, é melhor você utilizar o quê? Active Record, já que você está trabalhando dessa forma. Toma cuidado, tá? Escolha o formato que você quer trabalhar. Se você for trabalhar com domínio anêmico, ok. Muitas vezes não tem problema, principalmente quando você está trabalhando de um para um em sistemas mais simples. Agora, domínio complexo, meu querido amigo ou amiga, esqueça de trabalhar com domínio anêmico. Vai dar mega trabalho ao longo do tempo para você dar manutenção. E pergunta para mim como que eu descobri isso. Então vamos lá. Agora algumas anotações importantes Para resumir a história Domínio simples Active Record Domínios complexos Data Mapper Não há verdade absoluta O que eu estou colocando aqui É uma espécie de generalização De quando você deve utilizar uma coisa ou outra Isso não significa que você vai levar isso a ferro e fogo e falar amanhã, olha, está vendo esse projeto seu aqui, meu amigo? Está errado porque é domínio complexo, então você está usando o Active Record e você está errado. Não, não é assim. Mas, em vias de regra, eu faria essa recomendação aí para você. Então, pense bem na hora que você for conseguir trabalhar aí. No próximo vídeo, a gente vai falar sobre alguns pontos aqui em relação à atomicidade. Então, vamos nessa!