Bom pessoal, a gente falou de Transaction Script, a gente falou de Domain Model, mas tem um cara aí também que faz bastante sentido, dependendo da situação, quando você vai trabalhar em determinados sistemas. E isso aí é o que mais acontece, principalmente em sistemas muito grandes e que tem comportamentos muito parecidos, que é o chamado de Table Module, o módulo em tabelas. O que isso significa? Significa que esse tipo de sistema, ele tende a ser organizado e orientado às tabelas do banco de dados. Muita gente hoje em dia fala que isso é errado, mas eu não digo que isso é errado digo que é uma outra abordagem e o porquê que essa abordagem ela tem as vantagens e desvantagens a gente vai entender mais para frente como que ela funciona a gente pega as regras de negócio da aplicação de acordo com as regras que a gente vai utilizar para persistir os dados que a gente vai trabalhar então se eu tenho pedido e itens de pedido você vai ter provavelmente um módulo ali alinhado ao pedido dessa tabela e o de item de pedido então você dá um é de item ele vai gravar os itens na tabela e você é de pedido fazendo a relação desses itens nessa tabela então você é totalmente focado a isso qualquer vantagem é uma das coisas que é bem interessante nesse modelo é coesão as coisas que são iguais elas ficam juntas ali né a tabela de banco de dados ela representa como o sistema fala funciona e às vezes dependendo do sistema isso faz sentido realmente tá a isso também gera um acoplamento extremamente forte com o banco de dados né você é uma orientação a banco de dados realmente ea gente sabe que nos dias de hoje nem tudo consegue ser orientado à tabela de banco de dados tanto que muitos bancos de dados que a gente utiliza hoje em dia são no SQL. Eles não utilizam tabela, a gente não tem nem tabela como conceito. Então, isso é importante a gente conseguir trabalhar. Agora, vamos lá. Quais são os principais pontos que a gente trabalha aqui para a gente quando a gente está falando aqui? Deixa eu ver se eu... Eu acho que eu voltei aqui o slide então vamos lá quais são as principais vantagens que a gente tem aqui nesse ponto galera é muito simples trabalhar dessa forma né você cria vamos ver uma classe por tabela a o que vai gravar no banco é o que está representando ali na nas suas classes e acabou é fácil o mapeamento se faz mapeamento ali de um pra um e acabou é é muito fácil você passar esse esse tipo de coisa para uma pessoa que está começando a desenvolver no seu sistema legal é fácil ter manutenção se adicionou um campo novo se adiciona um campo numa tabela do banco um campo nova propriedade ali na sua classe, por exemplo, e está tudo certo ali também para você conseguir utilizar. E galera, por que esse modelo acontece muito hoje em dia? Ele é muito orientado a crude, se você perceber. Imagina só, galera, que você tem um sistema que ele tem sem crudes e esses crudes o que que ele faz no final do dia ele adiciona remove altera e depois você pode fazer uma busca ou gerar um relatório que no final do dia é o resultado daquele cara ou seja perceba você está pegando tabelas do banco de dados e está trazendo resultados dela entende então muitos rps dependendo da situação galera é são orientados à crude né muitas ferramentas low code no code hoje dia, elas são orientadas a crude e resolve. Eu não sei se você percebeu, mas eu não sei quão velho você é, mas lembra sistemas de locadora? Ou sei lá, eu tenho um RP que tem lista de fornecedores, listas de clientes, listas de funcionário. Eu adiciono um novo funcionário, adiciono um novo fornecedor, eu quero ver quanto que esse funcionário ganha, eu dou dois cliques e vejo quanto que esse funcionário ganha. Perceba, existem coisas na nossa vida que não tem nem lógica, não tem regra, é exibição, é pegar o dado e exibir relatório. Quando você está dessa forma, dependendo da situação, faz muito, mais muito sentido trabalhar dessa forma. faz muito, mas muito sentido trabalhar dessa forma. E o duro é que a gente tem que tomar muito cuidado, galera, com preconceitos ou a forma como a gente olha, porque dependendo da forma como a gente aprendeu a desenvolver, a gente pode criticar a forma como os outros desenvolvem. Mas você vai perceber que para cada contexto tem uma solução diferente. E acredite, trabalhar dessa forma faz muito sentido. Se alguém chegar para mim e falar, ó, você tem 100 crudes para resolver e você vai ter que ir criando esses crudes e relatórios desses crudes, ao invés de você ficar que nenhuma loucura mapeando o crude num modelo de domínio, que às vezes não tem nem tanta relação, as relações são sempre de um para um, trabalhar dessa forma vai resolver, é mais simples, é mais direto e acabou. Legal? Desvantagens. Como sempre, tudo tem desvantagem. Você vai ter muita duplicação de código. Porque se você não conseguir abstrair diretamente como as coisas funcionam, a sua duplicação vai aumentar infinitamente. Porque você vai ter diversos modelos fazendo exatamente a mesma coisa. Então, isso aí você tem que tomar muito cuidado. Outra coisa, você tem baixa reutilização. Eu não consigo pegar ali uma classe e reutilizar para um outro ponto, porque ela está extremamente ligada e acoplada a uma tabela do meu banco de dados então isso aí é importante a gente entender mas saibam galera tá a uma desvantagem é que você não foca em regras de domínio você está focando em inserção e exibição você não tem regras de negócio se você começar a precisar ter regras de negócio a coisa vai para o nível de complexidade extremamente alto agora se você pensa bem dá pra você misturar esses tipos de arquitetura num único sistema vamos imaginar que o meu sistema ele tem um corre muito bem desenhado que ele tem regras extremamente forte a gente vai pelo middle out pelo meio da aplicação essa parte eu posso fazer uma modelagem de domínio forte mas existem partes do sistema que são só cruzes que raramente né vão fazer parte do seu modelo de domínio forte e esses cruzes ele simplesmente auxiliam em parte do sistema não vai matar ninguém se a gente trabalhar dessa forma entende o que eu estou dizendo então por isso que eu digo um arquiteto um bom desenvolvedor é o cara que sabe as possibilidades, e que sabe que não existe 8 ou 80, existe um caminho do meio, e esse caminho do meio pode salvar tempo, pode trazer economia, conforme as coisas vão evoluindo, você vai mudando. Então tome cuidado na forma como você desenvolve software. Dependendo do software que você desenvolver, eventualmente trabalhar com modelagem de domínio vai fazer sentido. Beleza? Então, está aqui o Table Module aí para a gente.