![[The AI Show Episode 144]: ChatGPT’s New Memory, Shopify CEO’s Leaked “AI First” Memo, Google Cloud Next Releases, o3 and o4-mini Coming Soon & Llama 4’s Rocky Launch](https://www.marketingaiinstitute.com/hubfs/ep%20144%20cover.png)
![Blue Archive tier list [April 2025]](https://media.pocketgamer.com/artwork/na-33404-1636469504/blue-archive-screenshot-2.jpg?#)
.png?#)
-Baldur’s-Gate-3-The-Final-Patch---An-Animated-Short-00-03-43.png?width=1920&height=1920&fit=bounds&quality=70&format=jpg&auto=webp#)
![Alleged Pixel 10 series wallpapers leak with vibrant colors and a strange new theme [Gallery]](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/04/pixel-10-wallpaper-leak-1.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1){kind=tracking}
![Apple to Split Enterprise and Western Europe Roles as VP Exits [Report]](https://www.iclarified.com/images/news/97032/97032/97032-640.jpg)
![Nanoleaf Announces New Pegboard Desk Dock With Dual-Sided Lighting [Video]](https://www.iclarified.com/images/news/97030/97030/97030-640.jpg)
![Apple's Foldable iPhone May Cost Between $2100 and $2300 [Rumor]](https://www.iclarified.com/images/news/97028/97028/97028-640.jpg)
Domain Model e as entidades persistíveis
Quando se adota o design de Domain Model Pattern, ao invés da abordagem de Transaction Script Pattern, você tem em seu projeto tanto as entidades de domínio quanto as entidades correlatas de persistência? Às vezes nos perguntamos se o Domain Model Pattern traz consigo essa obrigatoriedade das entidades persistíveis. Primeiramente, vamos clarear algumas ideias, trazendo algumas definições/premissas: Sobre as Entidades de domínio No Domain Model, as entidades de domínio são fundamentais. Elas representam os conceitos principais do domínio da aplicação (por exemplo: Cliente, Pedido, Produto). Essas entidades encapsulam o estado (atributos) e o comportamento (métodos e regras de negócio relacionadas ao conceito) de forma coesa. Sobre as Entidades persistíveis Em um sistema bem projetado com Domain Model, as entidades de domínio podem ser persistidas, mas o foco principal delas não é a persistência, e sim o modelamento do domínio. A persistência é geralmente tratada por meio de técnicas como mapeamento objeto-relacional (ORM) (ex.: Hibernate, JPA) ou repositórios, que fazem a ponte entre o modelo de domínio e a infraestrutura de persistência (banco de dados). A grande questão dessa postagem é: A separação é necessária? Nem sempre é necessário criar uma distinção explícita entre entidades de domínio e entidades persistíveis. Em muitos casos, as entidades de domínio são diretamente persistíveis, desde que a infraestrutura permita isso sem comprometer o design do domínio. Porém, em sistemas mais complexos, pode ser útil separar os dois contextos para evitar acoplamento excessivo com detalhes de persistência. Nesse caso, você pode utilizar Data Models para transporte de dados. Diferença em relação ao Transaction Script No Transaction Script, as entidades geralmente são estruturas de dados simples (como tabelas ou registros), e a lógica de negócio é tratada de forma procedural em scripts ou serviços. Isso pode levar a um design mais simples, mas menos escalável e mais difícil de manter em sistemas complexos. Essa abordagem é mais direta e se concentra em scripts separados que executam operações específicas. Ele é útil em sistemas mais simples ou onde a lógica de negócios é de fácil entendimento. No Domain Model, a lógica de negócio é distribuída entre as entidades de domínio, promovendo coesão e encapsulamento, mas exige maior planejamento e cuidado no design. Essa abordagem foca em encapsular lógica de negócios complexa em objetos orientados a dados. Ele é ideal para aplicações que têm um comportamento intricado e persistente Conclusão No design de Domain Model: As entidades de domínio são indispensáveis, pois representam os conceitos e comportamentos do domínio. A distinção entre entidades de domínio e entidades persistíveis depende da complexidade do sistema e do grau de desacoplamento desejado entre a lógica de negócio e a infraestrutura de persistência. Vídeos no YouTube que podem ser usados como exemplos práticos: How To Start Using Domain-Driven Design: Pushing Logic Down - https://www.youtube.com/watch?v=q74saF54w8I Refactoring From Transaction Script to Domain-Driven Design - https://www.youtube.com/watch?v=KTSpDZNfjhU Transaction Script vs. Domain Model, qual estratégia de design devo adotar? - https://www.youtube.com/watch?v=tcZP0DlZD9U
Quando se adota o design de Domain Model Pattern, ao invés da abordagem de Transaction Script Pattern, você tem em seu projeto tanto as entidades de domínio quanto as entidades correlatas de persistência? Às vezes nos perguntamos se o Domain Model Pattern traz consigo essa obrigatoriedade das entidades persistíveis.
Primeiramente, vamos clarear algumas ideias, trazendo algumas definições/premissas:
Sobre as Entidades de domínio
- No Domain Model, as entidades de domínio são fundamentais. Elas representam os conceitos principais do domínio da aplicação (por exemplo: Cliente, Pedido, Produto).
- Essas entidades encapsulam o estado (atributos) e o comportamento (métodos e regras de negócio relacionadas ao conceito) de forma coesa.
Sobre as Entidades persistíveis
- Em um sistema bem projetado com Domain Model, as entidades de domínio podem ser persistidas, mas o foco principal delas não é a persistência, e sim o modelamento do domínio.
- A persistência é geralmente tratada por meio de técnicas como mapeamento objeto-relacional (ORM) (ex.: Hibernate, JPA) ou repositórios, que fazem a ponte entre o modelo de domínio e a infraestrutura de persistência (banco de dados).
A grande questão dessa postagem é: A separação é necessária?
Nem sempre é necessário criar uma distinção explícita entre entidades de domínio e entidades persistíveis. Em muitos casos, as entidades de domínio são diretamente persistíveis, desde que a infraestrutura permita isso sem comprometer o design do domínio.
Porém, em sistemas mais complexos, pode ser útil separar os dois contextos para evitar acoplamento excessivo com detalhes de persistência. Nesse caso, você pode utilizar Data Models para transporte de dados.
Diferença em relação ao Transaction Script
- No Transaction Script, as entidades geralmente são estruturas de dados simples (como tabelas ou registros), e a lógica de negócio é tratada de forma procedural em scripts ou serviços. Isso pode levar a um design mais simples, mas menos escalável e mais difícil de manter em sistemas complexos. Essa abordagem é mais direta e se concentra em scripts separados que executam operações específicas. Ele é útil em sistemas mais simples ou onde a lógica de negócios é de fácil entendimento.
- No Domain Model, a lógica de negócio é distribuída entre as entidades de domínio, promovendo coesão e encapsulamento, mas exige maior planejamento e cuidado no design. Essa abordagem foca em encapsular lógica de negócios complexa em objetos orientados a dados. Ele é ideal para aplicações que têm um comportamento intricado e persistente
Conclusão
No design de Domain Model:
- As entidades de domínio são indispensáveis, pois representam os conceitos e comportamentos do domínio.
- A distinção entre entidades de domínio e entidades persistíveis depende da complexidade do sistema e do grau de desacoplamento desejado entre a lógica de negócio e a infraestrutura de persistência.
Vídeos no YouTube que podem ser usados como exemplos práticos:
- How To Start Using Domain-Driven Design: Pushing Logic Down - https://www.youtube.com/watch?v=q74saF54w8I
- Refactoring From Transaction Script to Domain-Driven Design - https://www.youtube.com/watch?v=KTSpDZNfjhU
- Transaction Script vs. Domain Model, qual estratégia de design devo adotar? - https://www.youtube.com/watch?v=tcZP0DlZD9U
