Bom pessoal, no vídeo anterior eu dei uma geral do Active Record e falei também um pouquinho para você a minha opinião pessoal. Agora, a gente tem aqui algumas recomendações de quando você não deve usar Active Record. E essas recomendações, inclusive, você vai poder ver no próprio livro do Patterns of Enterprise Application Architecture. E quais são as recomendações que a gente tem aqui? no próprio livro do Patterns of Enterprise Application Architecture. E quais são as recomendações que a gente tem aqui? Domínio complexo. Você vai ter um domínio extremamente complexo. Na minha opinião, você realmente não deve usar Active Record. Imagina que você está fazendo um sistema financeiro, vai ter cálculos, vai ter muita regra de negócio, você vai ter que estender esse sistema de uma forma extremamente forte, você vai ter diversas estratégias, diversos cálculos, diversas métricas, você vai ter que fazer esse sistema crescer ao longo do tempo, às vezes esse sistema vai utilizar diversos mecanismos de persistência de dados. Aí nesse caso, galera, não utilize Active Record. Você vai perceber que o seu domínio novamente ele vai ter um descolamento muito grande seu banco de dados e no meio desse descolamento você vai ter que ficar fazendo muita interface para fazer esses caras falarem e vai gerar um nível de complexidade muito grande então por um lado em domínio simples o active Active Record vai salvar a sua vida, vai te dar um boost de produtividade. Para domínios complexos, você vai ver que o Active Record vai poder te dar um boost de trabalho para conseguir trabalhar com persistência de dados. Outro ponto importante. O Active Record precisa de um match exato com as tabelas de banco de dados tá então tem que ser de um pra um então você tem pedido tem de é preço o cliente no active record você vai ter que ter exatamente esses campos ou com pequenas variações ou dependendo da biblioteca você pode colocar apelidos mas o fato é se você quer trabalhar com Active Record, você vai saber que você vai ter que espelhar o seu banco de dados. E já dá para perceber que nos dias de hoje, para domínios complexos, você não vai espelhar esse banco de dados, então acho que nem adianta você começar a utilizar Active Record. E aí, você que trabalha com Laravel, Django, Rails, etc, etc, pode falar, E aí, você que trabalha com Laravel, Jungle, Rails, etc, etc, pode falar, poxa Wesley, eu já fiz um monte de projeto complexo utilizando o Active Record. Eu falo para você, parabéns. Talvez o seu domínio não tenha crescido ao ponto de gerar uma confusão muito grande. Mas você vai perceber que quando eu falo em domínios complexos, normalmente a modelagem, comportamento e atributos desses caras não necessariamente vai respeitar o banco de dados. Se você chegar nesse ponto, você vai perceber que Active Record não é para esse tipo de caso. Olha aqui, conforme a complexidade do domínio aumenta, os objetos de domínio deixam de ser um a um com o banco. Essa é uma pegadinha também, galera. Vocês têm que tomar cuidado. Às vezes você começa com um projeto simples e ele é um a um para o banco de dados do seu domínio. Então você vai lá e usa Active Record. Para esses projetos em que você não vê muita ambição para crescimento, tudo ok. a ambição para crescimento, tudo ok. Mas se você está começando um projeto agora e você sente que daqui a um ano ele já vai estar um monstro, não comece utilizando o Active Record. Minha opinião, novamente, aqui também. Tá, galera? Você é desenvolvedor, desenvolvedora, você é crescidinho o suficiente para saber as tecnologias. Mas se vocês querem uma opinião pessoal, vai crescer muito. Domínio complexo, esquece Active Record. Próximo vídeo a gente vai falar desse cara aqui, Data Mapper. Legal? Vamos nessa.