Bom pessoal, falado em Transaction Script, agora a gente vai para o outro ponto aqui, dentro dessa categorização interna da nossa aplicação, que é a parte de Domain Logic. O que é o Domain Model, galera? O Domain Model é o domínio de uma aplicação. E nesse caso aí, a gente está falando em objetos de domínio. O que isso significa significa que a lógica do seu negócio ela é separada em objetos tá e normalmente tá a a gente tem uma aplicabilidade muito grande principalmente quando está falando de orientação objetos isso não significa que se você estiver trabalhando com um paradigma mais funcional, que você não consiga. Você consegue sim, mas de forma geral, a gente vê isso muito mais aplicado em orientação a objetos, porque vai ficando mais claro a forma de como as coisas se abstraem. Mas nada implica aí de você trabalhar de uma forma mais funcional e coisas desse tipo, tá? Então, o que acontece? Quando você tem objetos de domínio, você vai perceber que esses objetos, eles encapsulam a lógica de negócios, tá? Então, você modela as suas regras baseadas em objetos que vão se conversando e que vão gerando um resultado final. Legal? Se você perceber, quando a gente trabalha com modelo de domínio, no final do dia, as regras de negócio sempre vão estar em primeiro lugar. Você não está pensando em trans primeiro lugar você não tá pensando em transação você não está pensando em banco de dados você não está pensando em apresentação você está simplesmente pensando em resolver o problema de negócio tá esse é o grande ponto enquanto por exemplo um transaction script ele quer realizar aquelas transações para fazer uma tarefa, o domain model tenta transformar a complexidade do seu software em modelos que vão se expressando de acordo com o que esses componentes vão falando. Uma coisa importante é que o domainingo ele faz ele se valida o tempo inteiro como isso assim como assim ele mantém a variância do estado do seu sistema ou seja você garante um sistema com estado a um estado muito forte por exemplo, se eu tenho um pedido com diversos itens, o total do pedido vai bater com o total de todos os itens. Não vai ter a chance de a soma dos itens mudar o total do pedido. Por quê? Porque houve regras de negócio, houve regras de validação que impedem esse tipo de coisa. Não tem como eu dar um set total e colocar um milhão e adicionar três pedidos de mil e daí o total vai ser um milhão. Por quê? Porque o sistema mantém o estado de forma coerente. Para você adicionar aquele total, ele invariavelmente tem que somar a quantidade de itens para o total ser gerado. Entende o que eu estou colocando? Não existe incoerência dentro do estado da sua aplicação. Ou seja, você consegue deixar a sua aplicação expressiva e muito coesa, de acordo com todas as regras que ela vai ter que executar. Legal? Quais são as vantagens de você trabalhar dessa forma com o domain model? Você tem clareza e expressividade. Você olha para aquele modelo e você fala, eu vou adicionar três pedidos e eu vou ter o resultado daquele pedido. Eu vou adicionar um novo cliente e quando adicionar um cliente, ele vai ter todas as validações, ele vai verificar se o cliente é ouro, ele vai verificar se o cliente é prata, se o cliente for ouro, ele vai fazer isso, se o cliente for prata, ele vai fazer aquilo. E tudo isso, independente de banco de dados ou qualquer coisa, ele vai aparecer para você aquele programa de faculdade que você fazia, onde tudo aquilo ali está carregado principalmente na memória. Então você olha aquele modelo e aquele modelo vai expressar o que o domínio representa. Um ponto importante é que isso vai dando para a gente muita flexibilidade. Por que dá flexibilidade? Porque conforme o sistema vai evoluindo, você vai trocando e vai melhorando, vai estendendo esse tipo de modelo por isso que é muito importante a gente entender bastante de sólido de a padrões de projetos é design patins pra que pra que essa extensão do nosso programa faça com que o domínio mantenha coerente e que ele seja a evoluído ao longo do tempo sem quebrar o que já foi feito aquela história muito grande quando a gente está falando, por exemplo, de Solid, onde a gente está falando do Open Close Principal, por exemplo o sistema tem que ficar fechado para modificação, mas aberto para extensão quando a gente está trabalhando dessa forma o Domain Model grita pedindo isso para que o sistema possa ser flexível para ele crescer ou seja, o domain model grita pedindo isso para que o sistema possa ser flexível para ele crescer. Ou seja, o foco está muito grande na evolução do sistema ao longo do tempo com o domínio bem definido. Uma coisa que é super importante é que quando você tem e trabalha com o modelo de domínio, a testabilidade de tudo isso aí é incrível. Por quê? Porque você consegue, principalmente com testes de unidade, verificar que o comportamento da sua aplicação está muito correto, que ele está muito coeso. Por quê? Porque você, testando, você consegue brincar e testar objetos separados você consegue testar objetos em conjuntos e você consegue verificar o comportamento da sua aplicação você vai perceber que por exemplo quando a gente trabalha com transaction script a testabilidade é muito ruim porque a única coisa que você pode garantir é uma entrada e uma saída mas no meio do caminho você pode estar uma gororoba só quando você está trabalhando e testando o domínio model você pode testar cada pedacinho e depois fazer o teste geral e que tudo aquilo ali vai ter que bater bacana agora qualquer desvantagem de você trabalhar dessa forma. Normalmente a desvantagem é que existe uma complexidade inicial. Por quê? Porque fazer uma modelagem não é fácil. Às vezes você gasta semanas para criar cinco, seis classes para fazer com que a coisa funcione. Entende o que eu estou dizendo? Sendo que o Transaction Script a coisa é muito mais clara. Faça isso, faça isso, faça isso e acabou. No modelo, não. Você vai ter que fazer todo aquele comportamento se conversar para daí, quando você pedir para alguma coisa ser executada, esse comportamento acontecer para você trabalhar. Então, normalmente, a maioria dos softwares, você vai perceber que ela atende muito mais para um transaction script do que para um domínio. Por quê? Porque trabalhar com domínio é mais complicado. Hoje em dia, a gente vê muito mais claramente os softwares serem muito mais orientados a um modelo de domínio do que o modelo de transações mas você vai perceber se você pega software de dez anos atrás você vai começar a perceber que o as classes de domínio principalmente ela só tem get set não sei se você já viu a gente chama isso de domínio anêmico porque porque ele não tem comportamento e isso normalmente acontece porque porque não existe modelagem existe transações tá então isso é importante. A curva de aprendizado também é um pouco maior. Por quê? Qualquer pessoa que vai chegar ali, ela tem que entender o comportamento de um modelo inteiro. É diferente você ver como você adiciona pedidos, como você pega aquilo, como você pega aquilo, como ele vai gerar uma nota, do que simplesmente você olhar uma função que fala, gera pedido. Isso, isso, isso, isso, acabou. É muito mais fácil você olhar uma transação do que você olhar uma orquestra tocar, vamos dizer assim, entende? E a parte de escalabilidade e performance é algo um pouco mais complexo aqui nesse caso. E o porquê que eu estou dizendo isso? Dependendo do tipo de aplicação que você vai trabalhar, e que você está focado muito mais em escalabilidade e performance, às vezes você passa a perna um pouco nesse seu modelo de domínio para conseguir do outro, ganhar mais performance. Vamos imaginar que você precisa trabalhar com um sistema que tem que ter uma locação de dados na memória muito pequena. Você vai tender a perceber que você vai estar muito mais ligado em realizar uma transação do que necessariamente ir carregando diversos objetos na memória, objetos que às vezes são muito pesados, que contêm muita informação, para daí você sair executando o que você quer. Então, às vezes, quando você tem sistemas que precisam de muita velocidade, muitas vezes você não vai mapear o domínio e não vai fazer essa modelagem ou você vai facilitar um pouco essa modelagem para simplesmente realizar uma transação do início ao fim uma performance enorme é mas também tomando risco do comportamento não está tão coeso ali para gente legal então essa que a ideia principal aí de domain model. E eu acredito que ficou claro pra você que quando você vai trabalhar com domain model, você tá num outro universo de quando você vai trabalhar orientado a transações. Beleza? Então, vamos nessa.