Anemic Domain Model e sistemas sérios

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Quando nos ensinam OO sempre nos dizem que os objetos devem traduzir a realidade. Se o sistema é bancáro deve existir Conta e Banco e assim vai. E a isso se chama domain model (modelo de dominio). Mas as tecnologias java , especialmente jee , mas não só não nos levam a criar esse tipo de objetos, mas sim objetos que representam registros (linhas no banco de dados) e objetos que representam operações sobre eles. Isso gera os famosos DO , TO , DTO ... escolham ... e os Façades/Statless bean etc... modelo que se chamou de Anemic Domain model , modelo de dominio anémico.

Ora isso é muito bonito e concerteza eu gostaria de usar um domain model puro, mas :

1) O usuário aperta o botão de salvar ... o que acontece ? O que é que se invoca ? concerteza não dá para invocar o objeto de dominio directamente

2) Os dados nos objetos gráficos (inputs) viram objetos do dominio ? e nesse caso eles existem com a mesma "realidade" que os objetos que já estavam no dominio (prevalencia/persistencia) ? O que é um objecto de dominio "salvo" e um " a salvar" ?

3) Onde ficam as validações ? controlo de tela , mensagens , transação , persistencia , etc ... ?

Ou seja, é sério pensar que um sistema complexo , distribuido, com swing , multicamada, encapsulado, etc etc ... pode ser baseado no dominio que não seja anémico. Se sim , como ? Que exemplos de aplicações reais existem que não usem um modelo anémico ?

sergiotaborda wrote:
1) O usuário aperta o botão de salvar ... o que acontece ? O que é que se invoca ? concerteza não dá para invocar o objeto de dominio directamente

Dar dá, estude Naked Objects que é uma abordagem que lida exatamente com isso.

De qualquer forma, arquitetura de Camadas existe exatamente para que ao clicar o botão existam direcionadores de fluxo que levam a mensagem até os objetos de domínio. A mensagem entra pela Camada de Apresentação e segue até a de Negócios, sofrendo transofmrações no caminho.

sergiotaborda wrote:
2) Os dados nos objetos gráficos (inputs) viram objetos do dominio ? e nesse caso eles existem com a mesma "realidade" que os objetos que já estavam no dominio (prevalencia/persistencia) ? O que é um objecto de dominio "salvo" e um " a salvar" ?

Os dados digitados pelo usuário ou obtidos de qualquer outra forma vão popular objetos de domínio. Antes, provavelmente, eles vão popular objetos da Camada de Apresentação (como os próprios formulários) e aí sim temos este tipod e objeto que representa um botão, um controle gráfico, etc.

Acho que a dificuldade que você está tendo é separar objetos em Camadas.

sergiotaborda wrote:
3) Onde ficam as validações ? controlo de tela , mensagens , transação , persistencia , etc ... ?

Um objeto deve obedecer a um contrato que lhe define as invariantes, pre e pos condições. O objeto eh responsavel por obedecer estas regras, se nao sao seguidas ele esta em estado invalido e deve prosseguir como tal (provavelmente lançando uma excecao).

Resumindo: validacao eh feita pelo objeto de negocios, por conveniencia ou desempenho pode-se replicar validacao na interface, o que geralmente eh feito em sistemas web.

sergiotaborda wrote:
Ou seja, é sério pensar que um sistema complexo , distribuido, com swing , multicamada, encapsulado, etc etc ... pode ser baseado no dominio que não seja anémico. Se sim , como ? Que exemplos de aplicações reais existem que não usem um modelo anémico ?

Sim, o problema é exatamente que seus exemplos não estão separando as aplicações em Camadas.

Dos exemplos reais eu posso citar os sistemas de um dos maiores provedores de conteudo e Internet do Brasil, o software utilizado para comercializacao de commodities da maior empresa de energia eletrica do mundo, sistemas pre-pagos que provavelmente rodam na sua operadora de telefonia movel, gerencia da maior ferrovia do Brasil, sistemas de gestao de RH de uma das maiores empresas de hardware do mundo... soh o que lembro dentre os projetos que ja trabalhei.

E mais: trabalhar com Swing (ou qualquer coisa desktop) é ainda mais fácil do que web quando se trata de um domínio rico já que existe uma JVM no cliente.

Como falei, é uma questão de separar em Camadas.

JavaTeenager Membro desde: 30/03/2006 16:51:25 Mensagens: 197 Offline

excelente post pcalcado
tb tava em dúvida em relação a alguns aspectos assim

tem algum link pra artigos sobre isso?

http://www.fragmental.com.br/wiki

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

pcalcado wrote:

sergiotaborda wrote:
1) O usuário aperta o botão de salvar ... o que acontece ? O que é que se invoca ? concerteza não dá para invocar o objeto de dominio directamente

Dar dá, estude Naked Objects que é uma abordagem que lida exatamente com isso.

Mas o problema é por ai mesmo. No fim parece que o objeto é tão naked(despido) que temos que o vestir com um monte de camadas...

sergiotaborda wrote:
2) Os dados nos objetos gráficos (inputs) viram objetos do dominio ? e nesse caso eles existem com a mesma "realidade" que os objetos que já estavam no dominio (prevalencia/persistencia) ? O que é um objecto de dominio "salvo" e um " a salvar" ?

Os dados digitados pelo usuário ou obtidos de qualquer outra forma vão popular objetos de domínio. Antes, provavelmente, eles vão popular objetos da Camada de Apresentação (como os próprios formulários) e aí sim temos este tipod e objeto que representa um botão, um controle gráfico, etc.

O problema é esse. Se eu populo outros objetos que depois populam os de dominio isso vai dar no mesmo que usar TO pois esses objetos intermédios acabam sendo TO (mesmo que eles não pareçam TO, como um Map ou o Request)

Acho que a dificuldade que você está tendo é separar objetos em Camadas.

Para que o Domain Model funcione ele tem que estar na camada de negocio, mas até lá tem um monte de logicas a serem feitas e os dados têm que transistar por elas. Isso leva à necessidade de TO, que é exactamente o que o anemic model não quer. Parece contraditório.
Num domain model verdadeiro os ppr objetos de modelo seriam os TO e eu poderia invocar seus métodos em qualquer ponto do sistema.
O exemplo classico é a validação. Eu poderia fazer ela no cliente (no caso de swing) mas uma exceção não é suficiente, eu preciso de um framework de validação para isso. Mais uma vez vestindo o objeto e retirando dele a capacidade de se validar (colocando numa annotation por exemplo)

O famoso controlo de tela se o campo A = x , desabilita B não pode ficar no objeto de dominio mas é uma regra de negocio. Então no fim o objeto de dominio não tem qualquer importância face à quantidade de outros objetos em outras camadas. Ou seja: não é possivel de apenas uma classe inferir todo o comportamento relativo à entidade de negocio que ela representa em todas as camadas do sistema.

sergiotaborda wrote:
Ou seja, é sério pensar que um sistema complexo , distribuido, com swing , multicamada, encapsulado, etc etc ... pode ser baseado no dominio que não seja anémico.

Sim, o problema é exatamente que seus exemplos não estão separando as aplicações em Camadas.

Mas é exactamente ao separar em camadas que preciso dos TO e é exactamente ai que nasce o modelo anémico. Parece uma contradição. Não é ?

Dos exemplos reais eu posso citar os sistemas de um dos maiores provedores de conteudo e Internet do Brasil (...)

Não tem nenhum open source ?

sergiotaborda wrote:
Mas o problema é por ai mesmo. No fim parece que o objeto é tão naked(despido) que temos que o vestir com um monte de camadas...

Acho que você não entendeu. procure no Google sobre Naked Objects, é uma técnica de desenvolvimento apoiada por alguns frameworks como JMatter.

sergiotaborda wrote:
O problema é esse. Se eu populo outros objetos que depois populam os de dominio isso vai dar no mesmo que usar TO pois esses objetos intermédios acabam sendo TO (mesmo que eles não pareçam TO, como um Map ou o Request)

Não. Um TO é um objeto de transferência, ele possui responsabilidade de transferir dados de um canto para outro.

Um objeto de interface tem por responsabilidade lidar com input do usuário, não transferir dados. Um TO e um Request são muito diferentes, o Request representa a solicitação feita pelo usuário, que inclui dados e metadados.

sergiotaborda wrote:
Para que o Domain Model funcione ele tem que estar na camada de negocio, mas até lá tem um monte de logicas a serem feitas e os dados têm que transistar por elas. Isso leva à necessidade de TO, que é exactamente o que o anemic model não quer.

Não há necessidade de TO. Por que haveria?

Os objetos da Camada de Aplicação recebem os dados 'crus' e os transformam em objetos que são passados para a Camada de Negócios invocando fluxos específicos (como chamar métodos em um Service Layer). Novamente: d~e uma cofnerida na literatura sobre camadas.

sergiotaborda wrote:
Num domain model verdadeiro os ppr objetos de modelo seriam os TO e eu poderia invocar seus métodos em qualquer ponto do sistema.
O exemplo classico é a validação. Eu poderia fazer ela no cliente (no caso de swing)

Você pode fazer isso, depende apenas de como modela suas camadas.

sergiotaborda wrote:
mas uma exceção não é suficiente, eu preciso de um framework de validação para isso. Mais uma vez vestindo o objeto e retirando dele a capacidade de se validar (colocando numa annotation por exemplo)

Como mencionei já trabalhei muito com Swing (não na construção do frontend mas na respsota aos eventos) e não vi necessidade de framework de validação. O controlados dos componentes de tela dispara métodos nos objetos de negócio, por exemplo tentando criar um objeto usuario. O objeto usuario, que é da Camada de Negócios, percebe que foi criado, digamos, sem um atributo login. Neste momento ele dispara uma exceção que é pega pelo controlador e tratada na interface. Esse é o padrão MVC original (sem estas aberrações web).

sergiotaborda wrote:
O famoso controlo de tela se o campo A = x , desabilita B não pode ficar no objeto de dominio mas é uma regra de negocio. Então no fim o objeto de dominio não tem qualquer importância face à quantidade de outros objetos em outras camadas. Ou seja: não é possivel de apenas uma classe inferir todo o comportamento relativo à entidade de negocio que ela representa em todas as camadas do sistema.

Como mencionado acima isto não é o que se espera de um padrão MVC. O Model vai gerar exceções que são tratadas pela View, a View é quem vai desabilitar campos, exibir alertas, etc. em resposta a estas solicitações.

sergiotaborda wrote:
Mas é exactamente ao separar em camadas que preciso dos TO e é exactamente ai que nasce o modelo anémico. Parece uma contradição. Não é ?

Não há esta necessidade. Leia sobre Camadas. Mundo Java #15 tem um artigo sobre isso.

sergiotaborda wrote:
Não tem nenhum open source ?

É difícil achar aplicativos J2EE como open-source, eu não lembro de nenhum caso notável.

Uma dúvida: voce trabalhava antes com Delphi, VB ou algo parecido?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

pcalcado wrote:

sergiotaborda wrote:
Mas o problema é por ai mesmo. No fim parece que o objeto é tão naked(despido) que temos que o vestir com um monte de camadas...

Acho que você não entendeu. procure no Google sobre Naked Objects, é uma técnica de desenvolvimento apoiada por alguns frameworks como JMatter.

Cara, eu sei o que é...

sergiotaborda wrote:
O problema é esse. Se eu populo outros objetos que depois populam os de dominio isso vai dar no mesmo que usar TO pois esses objetos intermédios acabam sendo TO (mesmo que eles não pareçam TO, como um Map ou o Request)

Não. Um TO é um objeto de transferência, ele possui responsabilidade de transferir dados de um canto para outro.

Ora , e se eu crio o objeto na camada de view do swing, populo com os dados dos inputs, passo à camada de delegação do swing, que serializa o objecto e passa ao servidor, que desserializa e passa à camada de serviços que passa à camada de domino e à de persistência, não é transferência que eu estou fazendo ? Se não é, o que é então ?

Um objeto de interface tem por responsabilidade lidar com input do usuário, não transferir dados. Um TO e um Request são muito diferentes, o Request representa a solicitação feita pelo usuário, que inclui dados e metadados.

Eu discordo disso. Mas o ponto não é esse. O ponto é que em algum lugar do sistema eu preciso condensar inputs num objeto só. Seja qual for e implemente o padrão que for esse objecto não é um objeto de dominio.
Ele é um objecto auxiliar, um objeto de framework. Ora os objetos auxiliares são exactamente o que o Anemic Domain Model (ADM) não quer ter.
Então parece-me que existe uma contradição entre dizer que ADM é ruim e que devemos ter objetos de dominio com todas as regras dentro deles quando isso não é compatível com sistemas distribuídos.

Você afirma que sim. Ok. Então por favor me dê um exemplo de um objecto de dominio que vc tenha criado, que siga o padrão Domain Model e não o ADM.

sergiotaborda wrote:
mas uma exceção não é suficiente, eu preciso de um framework de validação para isso. Mais uma vez vestindo o objeto e retirando dele a capacidade de se validar (colocando numa annotation por exemplo)

Como mencionei já trabalhei muito com Swing (não na construção do frontend mas na respsota aos eventos) e não vi necessidade de framework de validação.

Vc não viu exatamente porque não trabalhou com o front end. Dê uma olhada no JGodies Validation para ver do que estou falando. Não basta dizer que está inválido, tem que dizer como, onde , porquê e como resolver. Essa informação está normalmente no validador e no help e não no objeto de domínio.

sergiotaborda wrote:
O famoso controlo de tela se o campo A = x , desabilita B não pode ficar no objeto de dominio mas é uma regra de negocio. Então no fim o objeto de dominio não tem qualquer importância face à quantidade de outros objetos em outras camadas. Ou seja: não é possivel de apenas uma classe inferir todo o comportamento relativo à entidade de negocio que ela representa em todas as camadas do sistema.

Como mencionado acima isto não é o que se espera de um padrão MVC. O Model vai gerar exceções que são tratadas pela View, a View é quem vai desabilitar campos, exibir alertas, etc. em resposta a estas solicitações.

Que seja. O uso de MVC apenas reforça o que eu disse: não é o objeto do domínio que contém a regra daquilo que acontece na tela.

Básicamente a minha dúvida é saber se definindo uma classe com todos os atributos e métodos, junto com anotações especiais eu a posso usar em toda e qualquer camada da aplicação. Exemplo: A camada de validação usa as anotações de valdiação, a camada de persistencia usa as anotações de persistencia, etc etc.. apenas a camada de negócio usa os métodos da classe que "fazem alguma coisa".

Uma dúvida: voce trabalhava antes com Delphi, VB ou algo parecido?

Não. Nunca trabalhei com isso. Eu programei com eles, especialmente com VB e fiz alguma coisa - básicamente manutenção de programas já existentes - mas não foi do meu agrado e por isso mudei para Java por isso (entre outras razões). Mas o Java é uma tecnologia e por isso é necessário cria/usar padrões/frameworks para facilitar as coisas. Eu tenho ouvido falar do ADM e concordo com a ideia, mas não me parece que seja aplicável a uma aplicação séria. Por exemplo BPM é um modelos anémico logo à partida e é um modelo muito mais Business-friendly que Domain Model. Domain Model não se dá bem com aplicações destribuidas. É isso que quero saber. Se sim , ou não e em que medida.

O uso de um Domain Model independe da topologia da tua aplicação. Ele simplesmente serve para modelar de maneira mais clara e intuitiva os conceitos do negócio.

Todo sistema vai ter muitos objetos auxiliares e não relacionados ao modelo que fazer o plumbing necessário. O uso de DDM diz respeito a parte do sistema que cuida das regras do negócio e não tem o menor relacionamento com a camadas de infra-estrutura.

O sistema pode sim ser distribuido, precisar DTOs e tudo mais, mantendo um domain model na parte que cabe dele. Outra coisa, em algumas situações é possivel e interessante mapear coisas como validação e workflows como objetos de domínio. DDD diz muito a respeito da comunicação com o cliente, por exemplo, se ele quer discutir sobre "os cenários no qual XXX é pertinente", o desenvolvedor acaba por modelar isso como um objeto do modelo, apesar de ser só validação.

Tocando no assunto dos TO, eu sempre tive dúvidas de como fazer a comunicação de um cliente swing com um ejb de fachada, por exemplo, sem o uso de TO. Isso é possível de ser feito? O uso de TOs transforma o meu modelo num Anemic Domain Model?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

louds wrote:O uso de um Domain Model independe da topologia da tua aplicação. Ele simplesmente serve para modelar de maneira mais clara e intuitiva os conceitos do negócio.

Todo sistema vai ter muitos objetos auxiliares e não relacionados ao modelo que fazer o plumbing necessário. O uso de DDM diz respeito a parte do sistema que cuida das regras do negócio e não tem o menor relacionamento com a camadas de infra-estrutura.

Ah! era isso que eu queria ler. Essa foi tb a conclusão a que cheguei.
Mas nesse caso como eu faria a associação dos TO com os Objetos de Dominio. Exemplos ? ....

sergiotaborda wrote:
Ora , e se eu crio o objeto na camada de view do swing, populo com os dados dos inputs, passo à camada de delegação do swing, que serializa o objecto e passa ao servidor, que desserializa e passa à camada de serviços que passa à camada de domino e à de persistência, não é transferência que eu estou fazendo ? Se não é, o que é então ?

Sim, e nesse caso você deve utilizar um DTO (na maioria das vezes), ninguém nunca disse o contrário.

sergiotaborda wrote:
Eu discordo disso. Mas o ponto não é esse. O ponto é que em algum lugar do sistema eu preciso condensar inputs num objeto só. Seja qual for e implemente o padrão que for esse objecto não é um objeto de dominio.
Ele é um objecto auxiliar, um objeto de framework. Ora os objetos auxiliares são exactamente o que o Anemic Domain Model (ADM) não quer ter.

Qual o problema do objeto do framework (Controller, por exemplo) instanciar e enviar apra a Camada de Negocios um objeto de dominio? o que ele nao faz é processar regras de negócio.

sergiotaborda wrote:
Então parece-me que existe uma contradição entre dizer que ADM é ruim e que devemos ter objetos de dominio com todas as regras dentro deles quando isso não é compatível com sistemas distribuídos.

Para este tipo de coisa existe o apdrão DTO, leia a descrição no POEAA.

sergiotaborda wrote:
Você afirma que sim. Ok. Então por favor me dê um exemplo de um objecto de dominio que vc tenha criado, que siga o padrão Domain Model e não o ADM.

Leia os artigos em:
http://fragmental.com.br/wiki

sergiotaborda wrote:
Vc não viu exatamente porque não trabalhou com o front end. Dê uma olhada no JGodies Validation para ver do que estou falando. Não basta dizer que está inválido, tem que dizer como, onde , porquê e como resolver. Essa informação está normalmente no validador e no help e não no objeto de domínio.

Sérgio: a View sabe reagir ao Modelo, isso é o feijão-com-arroz do MVC. Se o modelo lança uma DataInvalidaException a view deve saber reagir a isso.

sergiotaborda wrote:
Que seja. O uso de MVC apenas reforça o que eu disse: não é o objeto do domínio que contém a regra daquilo que acontece na tela.

O que acotnece na tela está na Camada de Apresentação, que não é onde residem os objetos de negócio (eles são de domínio mas de um outro domínio, não o de negócios).

sergiotaborda wrote:
Básicamente a minha dúvida é saber se definindo uma classe com todos os atributos e métodos, junto com anotações especiais eu a posso usar em toda e qualquer camada da aplicação. Exemplo: A camada de validação usa as anotações de valdiação, a camada de persistencia usa as anotações de persistencia, etc etc.. apenas a camada de negócio usa os métodos da classe que "fazem alguma coisa".

Você simplesmente não deveria fazer isso.

De qualquer modo fica muito difícil continuar essa discussão de você não ler sobre:

- Camadas
- DTOs
- Naked Objects

Porque suas dúvidas são respondidas na bibliografia. Recomendo a laitura do POEAA, de Martin Fowler e dos artigos e apresentações do link que passei acima.

sergiotaborda wrote:
Ah! era isso que eu queria ler. Essa foi tb a conclusão a que cheguei.
Mas nesse caso como eu faria a associação dos TO com os Objetos de Dominio. Exemplos ? ....

http://www.fragmental.com.br/files/presentations/riojug/Arquitetura_de_Camadas_em_JEE_PDF.zip

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

pcalcado wrote:

sergiotaborda wrote:
Ora , e se eu crio o objeto na camada de view do swing, populo com os dados dos inputs, passo à camada de delegação do swing, que serializa o objecto e passa ao servidor, que desserializa e passa à camada de serviços que passa à camada de domino e à de persistência, não é transferência que eu estou fazendo ? Se não é, o que é então ?

Sim, e nesse caso você deve utilizar um DTO (na maioria das vezes), ninguém nunca disse o contrário.

Pois isto

diz exactamente o contrário. E essa imagem foi tirada daqui http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
Que é o site que vc recomenda tanto que eu leia.

De qualquer modo fica muito difícil continuar essa discussão de você não ler sobre:

- Camadas
- DTOs
- Naked Objects

O que é difícil é vc deixar de me tratar como seu eu tivesse 17 anos e prestar mais atenção na mensagem e menos no mensageiro.

Porque suas dúvidas são respondidas na bibliografia. Recomendo a laitura do POEAA, de Martin Fowler e dos artigos e apresentações do link que passei acima.

A verdade é que não são. Exactamente por eu ter lido sobre esses assuntos e essa "bibliografia" que eu tenho cheguei na conclusão que um sistema destribuido é anémico por natureza. Isto porque ele sempre seque aquele esquema da imagem acima , mesmo quando vc tiver verdadeiro objetos de dominio continua tendo objetos como aqueles que são basiacamente DTO e Service Layer.

Quanto ao PDF é muito bonito mas não tem os exemplo que eu pedi.

Calma sergio! O pcalcado só está ajudando. Se tu lesse o artigo direito veria que essa figura se refere ao Anemic Domain Model que o artigo mostra como problema e não como solução!

sergiotaborda wrote:
Pois isto
[...]
diz exactamente o contrário. E essa imagem foi tirada daqui http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
Que é o site que vc recomenda tanto que eu leia.

Se você tivesse perdido 15 minutos e lido o artigo veria que isso é um anti-exemplo. O artigo fala exatamente sobre como você deveria evitar este tipo de coisa, eu sei o que está escrito nele porque fui eu quem escreveu e recomendei tanto a leitura porque escrevi este texto e os outros exatamente para não precisar repetir estas coisas em todo santo post no GUJ.

sergiotaborda wrote:
O que é difícil é vc deixar de me tratar como seu eu tivesse 17 anos e prestar mais atenção na mensagem e menos no mensageiro.

A sua mensagem anterior só mostra que eu me enganei ao tentar conversar como você como alguém que quer aprender e ensinar algo. Você nem sequer leu o artigo (que se chama "Evitando VOs e BOs"). Logo abaixo desta figura ele fala sobre os problemas deste modelo.

O PDF tem o exemplo na parte sobre DTO (que é o mesmo do Fowler, está bem pequeno, é verdade, mas eu poderia te indicar outro material se você tivesse um mínimo de educação e interesse em procurar algo e não apenas expôr suas idéias que contradizem tudo que você diz que leu. Aliás até o texto de onde você tirou esta figura também tem um exemplo gráfico sobre DTO e uma explicação textual.

Bom, eu desisto de conversar com você, com a consciência limpa de ter tentado mesmo após tantas besteiras e tantos ataques em tantas outras trheads (é só ver o histórico do usuário acima).

É mais que óbvio que você quer concluir suas coisas partindo da sua própria opinião e se recusa a procurar mais sobre o assunto. Se alguém quiser conversar sobre este tema sinta-se a vontade, eu apenas não respondo mais ao colega acima nem neste tópico nem em qualquer outro.

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