Bom, eu sei que muita gente pode ter gerado um estranhamento entre diferenças entre Service Layer e Transaction Script, porque no final do dia a Transaction Script também pega diversos pontos, gera uma transação até o final. E o Service Layer também pega algo e concentra toda a lógica nas suas classes e também realiza a transação até o final. Então, afinal de contas, qual é a diferença entre um e outro? O lance é o seguinte, galera. Apesar de tantas service layers e os transaction scripts terem ideias semelhantes, eles possuem estruturas diferentes. A ideia dele é igual. Você não tem um modelo de domínio definido, você pega uma transação do início ao fim e resolve esse problema. O ponto é a estrutura que esses caras trabalham. O Transaction Scripts normalmente trabalham no formato de funções ou conjunto de funções específicas para cada operação. O que tende a gerar muita duplicação de código. Como assim? Normalmente, vamos imaginar que você quer realizar o pedido. O que tende a gerar muita duplicação de código. Como assim? Normalmente, vamos imaginar que você quer realizar o pedido. Então, em uma única função, você realiza todas aquelas lógicas até realizar o pedido inteiro. Você tem baixa composição de responsabilidades. Quando a gente trabalha com o Service Layer, o que vai acontecer? Você consegue flexibilizar maior porque você está trabalhando com as suas classes as suas classes têm responsabilidades as suas classes conseguem se falar elas conseguem gerar distrações entre elas e conforme você vai trabalhando dessa forma você tem mais flexibilidade normalmente transaction script Scripts segue muito paradigmas procedurais que faz uma coisa atrás da outra. Se você quer repetir algo semelhante, você duplica toda essa parada. Já com Service Layer, você tem a flexibilidade de trabalhar como mais ou menos com orientação a objetos, mesmo trabalhando de uma forma mais funcional, você consegue separar um pouco mais essas responsabilidades, você consegue ter um pouco mais de reuso aí no final do dia. Por outro lado, é importante ressaltar que ambas as abordagens, elas tendem a deixar o modelo de domínio de lado e elas são muito mais a orientados a casos de uso elas são muito mais orientados a resolver um problema do começo ao fim e se algo mudar você vai ter implicações em todos os sistemas e você acaba quebrando muito de geral, aqueles princípios do SOLID, principalmente o Open-Close Principle. Então, essa era apenas uma ideia que eu queria aqui, só para não gerar uma confusão entre esses dois pontos, porque eles parecem sim ser similares, galera. Então, pessoal, é importante a gente entender que toda essa base que eu te dei agora aqui no início foi pra você conseguir entender de onde vieram principalmente essas histórias de camadas domínio serviço transações a lógica de negócios camadaada de apresentação, banco de dados, CRUDs utilizando modelos de tabela, e o seu repertório, aos poucos, vai aumentando. Eu acredito que muito do que eu falei aqui, você já sabia de forma um pouco mais intuitiva. Mas quando as coisas vão ficando claras uma atrás da outra, você consegue entender quais são os melhores casos de uso e você não vai fazer mais ah, eu só vou trabalhar com modelo de domínio porque o fulano me falou. Ah, trabalhar com tabelas orientado a tabelas, banco de dados tá errado. Não tá errado. Depende do que você quer, tá? E é isso aí, é muito importante pra você. Grande abraço e até mais.