You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Luke Renn <go...@comcast.net> on 2005/04/19 23:09:43 UTC
Anemic Domain Model
Hello List,
I was just reading this:
http://www.martinfowler.com/bliki/AnemicDomainModel.html and was
wondering what Hivemind users think about it.
Do you agree? If not, what kinds of tasks to you leave for your
services, and what kind of logic do you reserve for your domain.
--
Luke | PGP: 0xFBE7D8AF
goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Anemic Domain Model
Posted by James Carman <ja...@carmanconsulting.com>.
Thank you very much for your kind words.
The Hibernate folks (Gavin King and Christian Bauer) would probably
recommend just using your domain entity classes to transfer the data between
tiers. The only problem with that is that you need to "pre fetch" all of
the relationships you're going to need in the other tier, since Hibernate
wouldn't be in place to do the "lazy" fetching for you.
If you do choose to use DTOs, however, I would create a package called
"hivemind.example.article.dto", since DTOs are not exactly part of the
domain model (IMHO).
Admittedly, my example does somewhat follow the "anemic domain model"
anti-pattern, since there is no real domain logic in the User class. Given
the simplistic requirements, though, there wasn't any real logic that
belonged in that class. I am used to programming in the usual "anemic" way
also. I only just recently picked up Eric Evans book on the advice of a
friend/colleague of mine. However, I really like how Mr. Evans prescribes
that you develop a domain model (factories, repositories, entities,
aggregates), at least as far as I've read. I'm still learning and I'm no
expert in this new way of thinking (yet). I still think HiveMind can be
useful when developing a "proper" domain model, though.
-----Original Message-----
From: Luke Renn [mailto:goseigen@comcast.net]
Sent: Thursday, April 21, 2005 11:46 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Anemic Domain Model
* James Carman <ja...@carmanconsulting.com> [2005-04-21 11:34:31 -0400]:
> implemented using something like Hibernate (see my article
> <http://www.theserverside.com/articles/article.tss?l=HivemindBuzz> at
> TheServerSide.com for an example of this), JDO, or just plain JDBC.
I agree %100, and infact, it was your article that made me start playing
with hivemind again. I don't know how I stumbled onto that article, but it
was the fact that your sample seemed to follow this amnemic model that
prompted me to ask. I loved the way you setup that sample project, and
thanks for the wonderful article. It had the added bonus of teaching me how
to fetch dependencies without all the baggage of maven.
Ah, I remember what I was looking for. In your domain directory you have
entity, factory, and repository. I was wondering where you would place
transfer objects (not persisted, no business logic) in your directory
structure. For example, if the EmailService took some hypothetical Message
object (and you didn't want to use an inner class). Anyway, like I said,
the article teaches you more than just hivemind, thanks for that.
--
Luke | PGP: 0xFBE7D8AF
goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Anemic Domain Model
Posted by Luke Renn <go...@comcast.net>.
* James Carman <ja...@carmanconsulting.com> [2005-04-21 11:34:31 -0400]:
> implemented using something like Hibernate (see my article
> <http://www.theserverside.com/articles/article.tss?l=HivemindBuzz> at
> TheServerSide.com for an example of this), JDO, or just plain JDBC.
I agree %100, and infact, it was your article that made me start
playing with hivemind again. I don't know how I
stumbled onto that article, but it was the fact that your sample
seemed to follow this amnemic model that prompted me to ask. I loved
the way you setup that sample project, and thanks for the wonderful
article. It had the added bonus of teaching me how to fetch
dependencies without all the baggage of maven.
Ah, I remember what I was looking for. In your domain directory you
have entity, factory, and repository. I was wondering where you would
place transfer objects (not persisted, no business logic) in your
directory structure. For example, if the EmailService took some
hypothetical Message object (and you didn't want to use an inner
class). Anyway, like I said, the article teaches you more than just
hivemind, thanks for that.
--
Luke | PGP: 0xFBE7D8AF
goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Anemic Domain Model
Posted by Nick Stuart <ba...@gmail.com>.
Right, which is basically how I do all my designs, with slight
variances of course. But that didn't sound like what the author of the
article posted was talking about. Maybe I just read it wrong or
something, but it didn't really make much, logical, sense to me.
-Nick
On 4/21/05, James Carman <ja...@carmanconsulting.com> wrote:
>
>
> Eric Evans (the author of Domain-Driven Design, which Fowler references)
> would not recommend that a User object knows how to store itself in a
> database. He would recommend creating a UserRepository class which
> represents the "set" of all of the User objects in the system. From the
> outside, the UserRepository should look and feel like an in-memory
> collection of User objects. Now, that repository could be implemented as
> exactly that, an in-memory collection. Or, more likely, it would be
> implemented using something like Hibernate (see my article at
> TheServerSide.com for an example of this), JDO, or just plain JDBC.
>
>
>
> -----Original Message-----
> From: Nick Stuart [mailto:baredok@gmail.com]
> Sent: Thursday, April 21, 2005 11:27 AM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Anemic Domain Model
>
>
> So basically he is saying that the application layer should do nothing more
> then call the Domain Layer objects which do all the work? In other words,
> not only does the Uesr object store the data, but also knows how to do
> everything else with the user as well right? (save to the database, load,
> delete, etc)
>
> I dont know, but that just feels wrong to me. The data is just that, data. I
> treat my simple POJO beans like that and everything seems to work out fine
> for me. My services are responisble for loading, saving, creating the data
> and thats it. What woud I gain by putting that in the User itself? He never
> mentions what you gain, just that you loose a lot of OO usuability (but
> never mentions specifics).
>
> His so called anti-pattern goes against almost everything I've read or been
> taught. But thats just me.
>
> -Nick
>
>
> On 4/19/05, Luke Renn <go...@comcast.net> wrote:
> > Hello List,
> >
> > I was just reading this:
> > http://www.martinfowler.com/bliki/AnemicDomainModel.html
> and was
> > wondering what Hivemind users think about it.
> >
> > Do you agree? If not, what kinds of tasks to you leave for your
> > services, and what kind of logic do you reserve for your domain.
> >
> > --
> > Luke | PGP: 0xFBE7D8AF
> > goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7
> > D8AF
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> hivemind-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> hivemind-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Anemic Domain Model
Posted by James Carman <ja...@carmanconsulting.com>.
Eric Evans (the author of Domain-Driven Design, which Fowler references)
would not recommend that a User object knows how to store itself in a
database. He would recommend creating a UserRepository class which
represents the "set" of all of the User objects in the system. From the
outside, the UserRepository should look and feel like an in-memory
collection of User objects. Now, that repository could be implemented as
exactly that, an in-memory collection. Or, more likely, it would be
implemented using something like Hibernate (see my article
<http://www.theserverside.com/articles/article.tss?l=HivemindBuzz> at
TheServerSide.com for an example of this), JDO, or just plain JDBC.
-----Original Message-----
From: Nick Stuart [mailto:baredok@gmail.com]
Sent: Thursday, April 21, 2005 11:27 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: Anemic Domain Model
So basically he is saying that the application layer should do nothing more
then call the Domain Layer objects which do all the work? In other words,
not only does the Uesr object store the data, but also knows how to do
everything else with the user as well right? (save to the database, load,
delete, etc)
I dont know, but that just feels wrong to me. The data is just that, data. I
treat my simple POJO beans like that and everything seems to work out fine
for me. My services are responisble for loading, saving, creating the data
and thats it. What woud I gain by putting that in the User itself? He never
mentions what you gain, just that you loose a lot of OO usuability (but
never mentions specifics).
His so called anti-pattern goes against almost everything I've read or been
taught. But thats just me.
-Nick
On 4/19/05, Luke Renn <go...@comcast.net> wrote:
> Hello List,
>
> I was just reading this:
> http://www.martinfowler.com/bliki/AnemicDomainModel.html and was
> wondering what Hivemind users think about it.
>
> Do you agree? If not, what kinds of tasks to you leave for your
> services, and what kind of logic do you reserve for your domain.
>
> --
> Luke | PGP: 0xFBE7D8AF
> goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7
> D8AF
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Anemic Domain Model
Posted by Nick Stuart <ba...@gmail.com>.
So basically he is saying that the application layer should do
nothing more then call the Domain Layer objects which do all the work?
In other words, not only does the Uesr object store the data, but also
knows how to do everything else with the user as well right? (save to
the database, load, delete, etc)
I dont know, but that just feels wrong to me. The data is just that,
data. I treat my simple POJO beans like that and everything seems to
work out fine for me. My services are responisble for loading, saving,
creating the data and thats it. What woud I gain by putting that in
the User itself? He never mentions what you gain, just that you loose
a lot of OO usuability (but never mentions specifics).
His so called anti-pattern goes against almost everything I've read or
been taught. But thats just me.
-Nick
On 4/19/05, Luke Renn <go...@comcast.net> wrote:
> Hello List,
>
> I was just reading this:
> http://www.martinfowler.com/bliki/AnemicDomainModel.html and was
> wondering what Hivemind users think about it.
>
> Do you agree? If not, what kinds of tasks to you leave for your
> services, and what kind of logic do you reserve for your domain.
>
> --
> Luke | PGP: 0xFBE7D8AF
> goseigen@comcast.net | 2A44 9EB2 F541 C1F2 D969 56E3 8617 5B7F FBE7 D8AF
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org