Domain Model

Andei dando uma olhada no link que o Phillip me indicou(este), e não sei se entendi direito, mas Domain Model seria basicamente tratar cada objeto como um elemento de um domínio? Tipo modelar os objetos de acordo com o domínio que eles pertencem?

Exemplo:
Objeto Caixa Eletrônico contém todas as propriedades(métodos) pertinentes a um Caixa ELetrônico e se relaciona com o Banco que por sua vez possui as propriedades pertinentes a um Banco.

É isso?

Olá,

Para mim, Domain Model é um conceito não exatamente um padrão.

num Domain Model você deve mapear entidades do seu processo (físicas ou abstratas) num modelo de classes que colaboram entre sí.

Segundo estes princípio, um sistema com requisitos de caixa de banco pode ter a estrutura que você, falou, mas lembre-se que tudo depende do ponto de vista do sistema. O sistema pode tratar todos os clientes como uma coisa só, sejam empresas multinacionais ou assalariados, ou pdoe ter um modelo onde estas entidades têm caractéristicas diferentes em dados e comportamento (não no valor dos seus dados, mas, por exemplo, uma regra de empréstimo muda).

Até aí tudo se parece muito com uma estrutura de entidades num SGBD (exceto pelas regras). A diferença é que objetos são ativos e não passivos como tabelas. Eles colaboram entre si, não ficam pulando de função em função, não se expõem aos outros mais do que devem (sua interface).

No livro, Fowler recomenda que você evite criar um modelo destes para aplicações muito simples (porque só o trabalho de modelar um domínio seria maior que a aplicação em si IMHO, como em muitos softwares CRUD que existem).

Tendo suas classes que realmente efetuam as ações do seu sistema, você pdoe definir Façades para sua lógica de negócio, evitando que seus clientes (um front-end gráfico, uma aplicação web, um outro sistema) saiba como os objetos estão implementados. Isso é o embrião de uma camada de negócios/domínio.

Modelar um sistema com objetos simples que se relacionam para cumprir tarefas é perfeito para realizar testes unitários e verificar se seu sistema está fazendo o que devia mesmo antes de se pensar numa arquiteutra de banco de dados ou uma interface de usuário para ele. Apenas crie casos de teste que manipulam seus objetos como você quiser.

Associados com Data Mappers (famigerados DAOs segundo a Sun), que recebem objetos de domínio a serem persistidos, um Domain Model bem feito constitui a camada de negócios de um sistema orientado à objetos atualmente.

A grosso modo então, DOmain Model seria uma modelagem das regras de negócio, o mais próximo do mundo real(ou o mais OO possível)?

Outra dúvida, cada 'processo' então seria um domínio? Onde determinados casos de uso relacionam-se entre si para cumprir determinada tarefa, isto seria um domínio, outras tarefas que seriam solucionadas por outros relacionamentos de casos de uso seria um outro domínio? Resumidamente, a camada de Business Logic seria um amontoado, um conjunto de domínios onde cada um é destinado a determinada tarefa?

Oi,

Rafael Nunes wrote:A grosso modo então, DOmain Model seria uma modelagem das regras de negócio, o mais próximo do mundo real(ou o mais OO possível)?

Sim, mas não o mais próximo possível, o mais próximo estritamente necessário para realizar a tarefa em questão.

Rafael Nunes wrote:
Outra dúvida, cada 'processo' então seria um domínio? Onde determinados casos de uso relacionam-se entre si para cumprir determinada tarefa, isto seria um domínio, outras tarefas que seriam solucionadas por outros relacionamentos de casos de uso seria um outro domínio? Resumidamente, a camada de Business Logic seria um amontoado, um conjunto de domínios onde cada um é destinado a determinada tarefa?

Em qual sentido você está falando "processo"?

Mas, do resto que eu entendi, não. O domínio da aplicação é o conjunto de objetos de domínio dela, e este domínio deve ser compartilhado entre as funcionalidades. Se você tem cosias muito alienígenas no seu domínio, talvez devesse partir o sistema em dois

This message was edited 1 time. Last update was at 30/03/2005 10:23:59

pcalcado wrote: Em qual sentido você está falando "processo"?

Mas, do resto que eu entendi, não. O domínio da aplicação é o conjunto de objetos de domínio dela, e este domínio deve ser compartilhado entre as funcionalidades. Se você tem cosias muito alienígenas no seu domínio, talvez devesse partir o sistema em dois

Hun, dá uma olhada neste modelo de Domain Model se puder:

Aqui esta basicamente mapeado um domínio de Order Service. Mas digamos que meu sistema tivesse outras funcionalidades, por exemplo se eu quisesse implementar um sistema de contablização, eu integraria os objetos deste sistema de contabilização junto com esses do Order Service para interagirem, ou criaria um domínio separado pra ele?

This message was edited 2 times. Last update was at 30/03/2005 10:23:41

Rafael Nunes wrote:Mas digamos que meu sistema tivesse outras funcionalidades, por exemplo se eu quisesse implementar um sistema de contablização, eu integraria os objetos deste sistema de contabilização junto com esses do Order Service para interagirem, ou criaria um domínio separado pra ele?

Contabilização...de Order Services? Use os objetos que você já tem, reuso é sempre a palavra

Resumindo: o domínio é um só. Ele é o seu sistema, o que tem além dele são interfaces e camadas auxiliares, como persistência, é na camada de domínio/negócios que a ação acotnece. Objetos de domínio participam em mais de um use case/estória/funcionalidade.

Numa metodologia incremental, você vai criar seu domínio conforme for seguindo implementando as estórias. No final, você vai ter que ir acrescentando coisas no seu domínio conforme for implementando tarefas especícias.

Num modelo cascata, com loooongas fases de análise e projeto, você vai (teoricamente, porque isso nunca dá certo) modelar seu domínio antes de começar a implementar.

Ps.: editei seu psot para colocar a figura com um [img]

pcalcado wrote: Numa metodologia incremental, você vai criar seu domínio conforme for seguindo implementando as estórias. No final, você vai ter que ir acrescentando coisas no seu domínio conforme for implementando tarefas especícias.

Certo, então o domínio do sistema é um só, onde os objetos colaboram entre si. Porém com o passar do tempo não fica bem fácil do domínio se tornar um conglomerado de objetos disconexos, repetitivos ou até mesmo uma grande bagunça?

Ps:SIm, creio que com experiência e conhecimento isso se torna mais difícil, mas ainda assim corre-se o risco, certo?

Rafael Nunes wrote:
Certo, então o domínio do sistema é um só, onde os objetos colaboram entre si. Porém com o passar do tempo não fica bem fácil do domínio se tornar um conglomerado de objetos disconexos, repetitivos ou até mesmo uma grande bagunça?

Me dá um exemplo do que você quer dizer.

Se você tem uma aplicação que gerencia bolas de encher, com funcionalidades simples:

1) Adicionar bola
2) Remover bola
3) Informar estouro de bola

E amanhã a gente precisa acrescentar:

4) Cobrar por bola estourada

Aidna que entrem classes de cobrança, bilhetagem, sei lá, continua sendo uma aplicação gerenciadora de bolas de encher, e você tem um domínio só.

Se você achar que o código de cobrança é tão importante (ou independente) que merece um isolamento maior, você pode definir uma camada para ele, transformando num componente fracamente acoplado à camada de negócios.

Rafael Nunes wrote:
Ps:SIm, creio que com experiência e conhecimento isso se torna mais difícil, mas ainda assim corre-se o risco, certo?

A experi~encia faz tanta coisa que não dá rpa explicar. Nada melhor que ler um livro e tentar implementar as idéias dele, por isso:

This message was edited 1 time. Last update was at 30/03/2005 11:22:49

Hun, creio que entendi.

Então o segredo é a modelagem, criar objetos, entidades, que possam ser reaproveitadas em situações diversas.
Pra que possa todo mundo se relacionar quando necessário.
Hei!Isso não é uma das proposta da OO, reutilização?!?

Grato pela explicação doutor.

This message was edited 1 time. Last update was at 30/03/2005 11:26:15

Rafael Nunes wrote:
Então o segredo é a modelagem, criar objetos, entidades, que possam ser reaproveitadas em situações diversars.

Quase... não ponha em seu domínio coisas que você não vai precisar tão cedo (leia aquilo de YAGNI que linkei, é muito legal). O grande pulo do gato é ser:

- Simples
- Flexível

O resto a gente muda quando for necessário

Estou muito chato hoje, por isso resolvi discordar de dois detalhes irrelevantes nesse ótimo post numa thread antiga.

pcalcado wrote:
Tendo suas classes que realmente efetuam as ações do seu sistema, você pdoe definir Façades para sua lógica de negócio, evitando que seus clientes (um front-end gráfico, uma aplicação web, um outro sistema) saiba como os objetos estão implementados. Isso é o embrião de uma camada de negócios/domínio.

Isso seria uma Service Layer? Tem seus usos, mas eu não acredito ser particularmente importante abstrair o domínio da apresentação. O código tem que ser separado, mas não vejo muito problema na UI ter dependências diretas para as regras de negócio.

pcalcado wrote:
Associados com Data Mappers (famigerados DAOs segundo a Sun)

Eu acho que os DAOs se assemelham mais ao Table Data Gateway e Row Data Gateway do que ao Data Mapper. Mas eu posso estar errado.

Ola,

AllMighty wrote:
Isso seria uma Service Layer? Tem seus usos, mas eu não acredito ser particularmente importante abstrair o domínio da apresentação. O código tem que ser separado, mas não vejo muito problema na UI ter dependências diretas para as regras de negócio.

Desde que sua camada de negócios não dependa da de apresentação, fazendo o mais simples tá ótimo

AllMighty wrote:
Eu acho que os DAOs se assemelham mais ao Table Data Gateway e Row Data Gateway do que ao Data Mapper. Mas eu posso estar errado.

Por que?

Na realidade, acho que os DAOs que vi/fiz ate´hoje mesclam os três padrões quando necessário.

Notícias, artigos e o maior fórum brasileiro sobre Java