Anemic Domain Model e sistemas sérios

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

mutano wrote: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!

Exactamente. O problema qual seria ? Ter dois tipos de objetos : os TO (VO,DTO, chamem como quiserem) e aquilo que o artigo chama de BusinessObject. Eu sei perfeitamente que isto não é um Domain Model porque um Domain model é a fusão daqueles dois objetos.

Ora , então a logica é: se TO é sinónimo de ADM , retirese o TO e deixe fica só o Objecto de Dominio (OD). O que o pcalcado falou é que pode usar TO que isso não contraria / impede usar OD. Mas o artigo e o prórpio principio do Anemic Domain Model diz exatamente o contrário. TO não existem num Domaim Model verdadeiro, só existem OD.

Mas o pcalcado não partilha desta opinião e falou que sim pode usar TO o que é uma contradição.
Eu partilho a opinião do louds que pode usar os dois e pedi exemplos de como encaixar os dois. MAS se eu usar essa forma, eu estarei automáticamente usando um Anemic Domaim Model. Nem o artigo, nem o Martin , nem ninguém até agora explicou como se usa Domain Model sem TO num ambiente destribuido. A minha opinião é que isso simplesmente não é possivel porque sempre teremos camadas inevitavelmente sempre teremos TO e portanto inevitavelmente caímos no ADM.

Olá, estou bem atento a esta thread, pois OO é algo que sempre me interessa... Porém ainda não entendi uma coisa: por exemplo, eu tenho um formulário de cadastro de disciplinas, o usuário entra com os dados da nova disciplina, quando ele clica no botão salvar, ele salvará estes dados em um objeto, será tratado e só então transferido ao domain model? É isto?

Ainda nãi está claro para mim.

Alguém possui exemplos web e/ou desktop para que eu possa entender melhor?

Sérgio, você tem certeza que leu o artigo do Fowler sobre DTOs? Por que lá está super claro como você faz para transformar entre o DTO e os objetos de domínio.

Se o idioma for problema, o tradutor do google deve dar conta, já que ele usa um ingles muito regular.

Inclusive, ele recomenda usar outro pattern do PEAA para resolver isso.

sergiotaborda wrote: Nem o artigo, nem o Martin , nem ninguém até agora explicou como se usa Domain Model sem TO num ambiente destribuido. A minha opinião é que isso simplesmente não é possivel porque sempre teremos camadas inevitavelmente sempre teremos TO e portanto inevitavelmente caímos no ADM.

Você leu isso sério?

One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn't an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model.

Nessa sua aplicação ultra complexa aí que talvez pudesse ser feita de forma bem mais simples mas por algum motivo tem que ser distrbuída, você poderia usar DTOs pra levar os dados do swing para o servidor chegando lá(na camada de serviços) você instancia um objeto de domínio e executa metódos de negócios que fazem parte única e exclusivamente dos seus objetos de domínio.
Você tem DTOs, apenas porque quer fazer sua aplicação distribuída mas seus objetos de domínio tem seus atributos e suas operações.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

sergiotaborda wrote:Nem o artigo, nem o Martin , nem ninguém até agora explicou como se usa Domain Model sem TO num ambiente destribuido. A minha opinião é que isso simplesmente não é possivel porque sempre teremos camadas inevitavelmente sempre teremos TO e portanto inevitavelmente caímos no ADM.

Concordo na parte que de qualquer jeito vc cai num ADM. Discordo na parte onde vc fala que o Martin não explicou. Ele explicou...

louds wrote:Se o idioma for problema, o tradutor do google deve dar conta, já que ele usa um ingles muito regular.

Comentário desnecessário.

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

louds wrote:Sérgio, você tem certeza que leu o artigo do Fowler sobre DTOs? Por que lá está super claro como você faz para transformar entre o DTO e os objetos de domínio.

Se o idioma for problema, o tradutor do google deve dar conta, já que ele usa um ingles muito regular.

Inclusive, ele recomenda usar outro pattern do PEAA para resolver isso.

Paternalismo à parte (que contnuo achando ofensivos)... e só para vcs terem a certeza que eu li aqui vai o texto relevante

"As a result I see two styles of Domain Model in the field. A simple Domain Model looks very much like the
database design with mostly one domain object for each database table. A rich Domain Model can look
different from the database design, with inheritance, strategies, and other [Gang of Four] patterns, and
complex webs of small interconnected objects. A rich Domain Model is better for more complex logic, but is
harder to map to the database. A simple Domain Model can use Active Record (160), whereas a rich Domain
Model requires Data Mapper (165)."

"When you're working with a remote interface, such (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each d to pro
call. One way to do this is to use lots of parameters. However, this is often awkwgram?indeed, it's
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable
to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO
and any domain objects."
in PEAA

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is very little behavior on these objects. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.
in http://www.martinfowler.com/bliki/AnemicDomainModel.html

Mas lá não tem nenhum código. Eu pedi exemplos de código que vcs já tenham usado nesta situação. Mas como já entendi que vcs não tem esses exemplos nem vou mais perguntar nada.

Eu acho claro que usar Domain Model pode ser compativel com TO embora os TO violem explicitamente o segundo texto que citei. Duplicando até os dados do dominio que podem ser complexos. É possivel ? sim. É Anemico ? Sim! é este o ponto que eu gostaria de discutir e não o que eu li ou deixei de ler, que idade eu tenho ou se sei inglês. OK !?

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

leomc wrote:
Nessa sua aplicação ultra complexa aí que talvez pudesse ser feita de forma bem mais simples mas por algum motivo tem que ser distrbuída, você poderia usar DTOs pra levar os dados do swing para o servidor chegando lá(na camada de serviços) você instancia um objeto de domínio e executa metódos de negócios que fazem parte única e exclusivamente dos seus objetos de domínio.
Você tem DTOs, apenas porque quer fazer sua aplicação distribuída mas seus objetos de domínio tem seus atributos e suas operações.

Eu dei esse exemplo porque é mais clara a necessidade de DTO, mas pode pensar em ambiente web usando ActionForms. Vai dar no mesmo. Vc usa objetos para conter os dados que não são objetos do dominio. Esses são os objetos anémicos que o Martin fala (anémicos pq não tem comportamentos de negocio)

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

Taz wrote:

sergiotaborda wrote:Nem o artigo, nem o Martin , nem ninguém até agora explicou como se usa Domain Model sem TO num ambiente destribuido. A minha opinião é que isso simplesmente não é possivel porque sempre teremos camadas inevitavelmente sempre teremos TO e portanto inevitavelmente caímos no ADM.

Concordo na parte que de qualquer jeito vc cai num ADM. Discordo na parte onde vc fala que o Martin não explicou. Ele explicou...

Ok. Cite essa explicação, ou explique qual é,pq eu não a encontrei.

sergiotaborda wrote:
Mas lá não tem nenhum código. Eu pedi exemplos de código que vcs já tenham usado nesta situação. Mas como já entendi que vcs não tem esses exemplos nem vou mais perguntar nada.

Eu acho claro que usar Domain Model pode ser compativel com TO embora os TO violem explicitamente o segundo texto que citei. Duplicando até os dados do dominio que podem ser complexos. É possivel ? sim. É Anemico ? Sim! é este o ponto que eu gostaria de discutir e não o que eu li ou deixei de ler, que idade eu tenho ou se sei inglês. OK !?

Não é paternalismo, mesmo porque seu significado não cabe, é simplesmente o fato que as respostas estão no texto de maneira clara e você parece que não lê.

Em um sistema distribuido você tem os Assemblers convertendo entre Domain Objects e os DTOs, fora essa conversão, teu modelo continua rico, pois todo comportamento não escapou do lugar que deveriam ficar.

Quanto ao que constitui aquilo que o Martin Fowler chama de Anemic Domain Model, como você mesmo colocou, é uma quimera, um engodo, é ter objetos que parecem/deveriam possuir comportamento rico, porém não passam de simples struts.

Seguindo essa linha, chamar um sistema que usa de DTO de anêmico não tem sentido, afinal, os objetos utilizados para transporte de rede fazem exatamente aquilo que se propoem e parecem. Ninguém vai confundir um DTO com um DO, no caso de ambos existir.

DTOs são um artifício para otimizar o transporte pela rede. Falar que eles invalidam o uso de domain modeling é tão sem nexo quanto dizer que por precisar converter de String para int o conteúdo de um textfield quando transfere o valor da GUI para o domain model, o sistema é anêmico.

Um sistema não existe somente com o domain model, existem muitas outras partes que não necessáriamente possuem um domínio, tão pouco precisem. O fato de ser anêmico, como o Fowler fala, a grosso modo, diz mais a respeito a programadores que escrevem código lixão achando que estão usando DDD e abafando.

Você quer código? Bom está ai seu código de como suar DDD com DTOs:

Veja nesse exemplo que: o DO possui comportamento; o DTO é usado apenas para transferencia de dados pela rede; e o Assembler é utilizado para conversão.

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

louds wrote:
Veja nesse exemplo que: o DO possui comportamento; o DTO é usado apenas para transferencia de dados pela rede; e o Assembler é utilizado para conversão.

Blz. Então agora me diga pq vc não pode simplesmente eliminar o DTO e fazer assim :

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Simples! Se for possível evitar o DTO, evite. Se você for obrigado a usá-lo (e isso acontece), use-o.

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

Thiago Senna wrote:Simples! Se for possível evitar o DTO, evite. Se você for obrigado a usá-lo (e isso acontece), use-o.

Embora o seu comentário seja tautologico a conclusão que eu queria chegar é : Você sempre pode evitar DTO.

Parece que cabe um resumo da opera...

1) Orientação Objetos ensina que Objeto é um ente que associa dados com comportamento sobre esses dados e que deve ser criado um modelo de dominio. O modelo de dominio é um conjunto de classes , relacionadas entre si, que possuem estado e comportamento.

2) Face à necessidade de criar aplicações em várias camadas e popularizado pela fraca especificação EJB 1 e 2 foram introduzidos os conceitos de objeto de transferencia (TO / DTO) e objeto de negocio (Bo/ EJB Statless) . O primeiro contém apenas estado e o segundo apenas comportamento.

3) Martin Fowler e outros defenderam que isso é um falso modelo de dominio porque desassocia o comportamento do estado violando portanto a permissa numero 1 de Orientação a Objetos. Ele chamou a este pseudo modelo de dominio : Modelo de Dominio Anémico (Anemic Domaim Model)
e defendeu que o dominio puro deva ser usado.

3.1) Martin Fowler e outros tb reconhecem que o dominio puro não é prático numa aplicação destribuida e portanto é necessário fazer uso de TO/DTO criando assim um modelo híbrido que funciona graças à introdução do papel do Assembler : um objeto que traduz DTO em Objetos de Dominio e vice-versa. Este modelo é semelhante ao usado em EJB até À versoa 2.1 quando Entity Beans são usado como objetos de negocio e têm que ser convertidos em DTO para possibilitar comunicação com as outras camadas/nodos do sistema.

sintese: Identiifa-se um anti-pattern , o anemic domaim model, e propoe-se uma solução igualmente anémica já que ao existrem objectos DTO é possivel que , em qualquer camada , sejam construidos objetos de negocio no estilo dos usados no modelo anémico. Parece então que o modelo anémico é intrinseco a aplicações destribuidas e portanto ele não seria um anti-pattern nesse tipo de aplicações.
Sendo que todas as aplicações sérias são distribuidas (por nodos ou camadas, ou ambos) o modelo anémico é portanto inevitável.
E é até defendido como se viu nas respostas deste tópico.

conclusão: Embora todo o mundo saiba dos males do modelo anémico e alerte para o seu não-uso , todo o mundo, simultaneamente aceita que ele deve ser usado. Isso para mim é um contradição grave , que demonstra a falta de viabilidade em aceitar a ideia que existe tal coisa como um modelo de dominio puro. Esta ideia é suportada na crescente onde de orientação a serviços (outro nome possivel para a figura dos objetos sem estado e só com funcionaldiade) junto com coisa como BPM.
Concluo portanto que , em sisteas sérios, não ha espaço para modelo de domínio puro e que o uso de DTO é inevitável.

Prólogo
Isto é verdade a menos que o próprio objeto de domínio possa fazer o papel de DTO. O que à partida parece simples. Basta fazer o objeto serializável. Por outro lado, um objeto de dominio pode depender de serviços externos , até mesmo de serviços de outras aplicações. Exemplo são a consulta de crédito no Serviço de Proteção ao Crédito, ou uma simples consulta de frete baseado no CEP dado pela empresa transportadora. Embora isto possa ser incluido como uma lógica no modelo de dominio, é na realidade uma lógica trans-dominio (entre dominios) e isso trás problemas práticos que são mais facilmente resoluveis se optarmos por um modelo anémico : objetos de dados + objetos de lógica/serviço/negocio.

Algo a acrescentar ?

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

ficaram algumas perguntas pendentes no meio desta conversa:

mutano wrote:
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?

RicardoLuis wrote:
Olá, estou bem atento a esta thread, pois OO é algo que sempre me interessa... Porém ainda não entendi uma coisa: por exemplo, eu tenho um formulário de cadastro de disciplinas, o usuário entra com os dados da nova disciplina, quando ele clica no botão salvar, ele salvará estes dados em um objeto, será tratado e só então transferido ao domain model? É isto?

Ainda nãi está claro para mim.

Alguém possui exemplos web e/ou desktop para que eu possa entender melhor?

O uso de TOs transforma o meu modelo num Anemic Domain Model?

o usuário entra com os dados da nova disciplina, quando ele clica no botão salvar, ele salvará estes dados em um objeto, será tratado e só então transferido ao domain model? É isto?

sergiotaborda wrote:
O uso de TOs transforma o meu modelo num Anemic Domain Model?

Não.

sergiotaborda wrote: o usuário entra com os dados da nova disciplina, quando ele clica no botão salvar, ele salvará estes dados em um objeto, será tratado e só então transferido ao domain model? É isto?

Normalmente é assim, a GUI dificilmente já traz tudo pronto e é por isso que existem os controllers. Eles recevem as informações da GUI, transformam em objetos que o Model entende e repassam pro Model fazer o que ele tiver que fazer.

Só estou com mais duas dúvidas:

1) Como é feita a passagem dos dados do TO para o Domain Model? Via uma façade?

2) Quem que efetua as chamadas ao DAO? O Domain Model? Ou entre o DAO e o Domain Model existe uma camada?

A ideia seria uma arquitetura da seguinte forma:
View -> Controller -> Façade -> Domain Model -> DAO

E para a passagem dos valores da view para o controller e para o domain model utiliza-se um TO?

A ideia é esta? entendi direito?

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