Dirk (not Roni!)
 
Sorry, didn't read your post carefully enough.  Regarding #2, I didn't quite understand this bit:
 
> In Hibernate you can get around that by declaring access to a field as access="field" which avoids using getters and setters but goes to the field
> directly. But then you won't get the benefit of the setter where necessary. For example, some of our value objects are immutable shared objects > > (Currency) and having an anonymously created instance floating around breaks that model. Going back to getter/setter field access doesn't cut it
> as the issue is independent of this.
 
If the objects are immutable, why does it matter if they are shared or not?  How does having a Hibernate created instance floating around break the model?
 
Steve

---

From: domaindrivendesign@yahoogroups.com [ mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
Sent: Wednesday, July 13, 2005 4:23 AM
To: domaindrivendesign@yahoogroups.com
Subject: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re: Repositories and Transaction Handling

Hi all,

we started using Hibernate about a week ago, and even though I think it is probably the best of the ORM tools available, it does get in the way with (a) proper domain modeling and (b) separating domain models from persistence layers.

I thought I'd describe the main issues I'm having right now---maybe someone knows a better solution or at least finds this interesting.

1. Value Objects. We have a whole library of value objects (an earlier version can be found on www.jvalue.org) and so we would like to map them into columns within the enclosing entity object's table.

Hibernate lets you specify value objects as components, but then you have to repeat the component structure any time you use a specific value object. For example, in an Account class, a balance attribute might be mapped like this:

<component name="balance" class="org.jvalue.finance.Money">
         <property name="amount" access="field" column="BALANCE"/>
         <component name="currency" access="field" class="org.jvalue.finance.Currency">
                 <property name="code" access="field" column="CURRENCY"/>
         </component>
</component>

If you use Money objects some other place, you have to repeat that same definition in that other class mapping definition. So much about redundancy.

Then I see Hibernate lets you specify classes as value objects, called user types. Unfortunately, you have to implement UserType or CompositeUserType. For us, this is out of the question, as we can't change/reimplement/extend our library that way. Wasn't a good OR Mapper supposed to be non-invasive?

2. Field access. Hibernate wants us to use getters and setter for loading/saving objects. This gets in the way of domain semantics, for example some of our (legacy) code uses old-style assertions, for example:

class Posting...

        public void setValidityDate(JDate date) {
                 // FIXME: assertIsNotSealed();
                 validityDate = JDate.getValue(date.asMilliseconds());
        }
}

assertIsNotSealed() throws an exception if this posting to a book had been carried out, hence sealed, and is supposed not to be touched. That behavior is part of the domain model for sure!

In Hibernate you can get around that by declaring access to a field as access="field" which avoids using getters and setters but goes to the field directly. But then you won't get the benefit of the setter where necessary. For example, some of our value objects are immutable shared objects (Currency) and having an anonymously created instance floating around breaks that model. Going back to getter/setter field access doesn't cut it as the issue is independent of this.

Anyway, long post, rather frustratedly, but still interesting, I hope.

Dirk


Interested in wikis? Please go to http://www.wikisym.org!
Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
Dirk Riehle | +49 172 184 8755 | http://www.riehle.org


        




At 12.07.2005, Billy McCafferty wrote:

There’s a great example of separating the transactional layer in Chapter 8 of “Hibernate in Action” by Christian Bauer and Gavin King.
 
Billy McCafferty
 
 
-----Original Message-----
From: domaindrivendesign@yahoogroups.com [ mailto:domaindrivendesign@yahoogroups.com] On Behalf Of andrew_raphael_small
Sent: Saturday, July 09, 2005 1:22 PM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Re: Repositories and Transaction Handling
 
--- In domaindrivendesign@yahoogroups.com, Rex Madden
<rexmadden@g...> wrote:
> Any OR mapping tool will have several options for handling
transactions. For
> example, in Hibernate, the simplest method is to pass a session to
your
> repository which is opened at the beginning of a request, and then
flushed
> and closed at the end of a request (assuming you are talking about
a web
> app). You can use a ServletFilter to do the opening and closing.
>  Of course, there are more sophisticated patterns for complicated
scenarios,
> but that's a good way to start.
>
>
> --
> Rex Madden

I would be very interested to learn about those more sophisticated
patterns.  Do you know some references that I can look at?  I want to
set up our application to use the simple pattern you describe but I
also want to be ready to address the complicated scenarios that we
may encounter.

Andrew Small



<?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?---- HM ADS ?>

---

YAHOO! GROUPS LINKS

•  Visit your group " domaindrivendesign" on the web.
•  To unsubscribe from this group, send an email to:
•   domaindrivendesign-unsubscribe@yahoogroups.com
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

<?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?---- HM ADS ?>

---

YAHOO! GROUPS LINKS

•  Visit your group " domaindrivendesign" on the web.
•  
•  To unsubscribe from this group, send an email to:
•   domaindrivendesign-unsubscribe@yahoogroups.com
•  
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

---

I've been enjoying this thread. I don't have much to add, but I'm
getting good insights from the discussion.

I wanted to comment on one thing:

Roni Burd wrote:

> One thing where I tend to see hibernate creeping into the model is
> with queries. There are 2 ways to do it in this case, the hibernate
> way or build your own query classes. The first one will but hibernate
> HQL or Query objects in your model, the second options take an
> investment of time to get right. But then again, in DDD books you see
> the specification pattern used to make queries and in the book there
> is SQL code in the specification code. If you put HQL code in there
> you will be in a similar position. Doing queries using repositories
> and specifications is meant so that this kind of functionality is at
> least encapsulated somewhere.
>
Roni gets it about right, I think. I just wanted to mention that I'd be
more likely to include SQL code in specification code in a book that I
would be in real life. The reason is that, in a book, you need an
example that anyone can understand after a quick read. There are no
maintenance issues. So SQL becomes a kind of universal shorthand for
conveying the intent of a query.

Now, I find that universality to be a selling point for SQL in general,
but there are serious maintenance issues involved in getting query code
mixed up in the model code, so I would ordinarily not do that. I try to
confine it to the repositories. Specifications can be in that same category.

In other words, I am echoing Roni's pragmatic statement. I just wanted
to throw in the comment that sometimes in books we write code
differently than we might in real life because it is not worth a
reader's investment in learning some specialized query expression language.

-Eric

Ramon Leon wrote:

>Eric, I just love the way you say, "it depends".
>
>
>
Ramon, did you sneak a peek at my first draft of my posting? :-)
Eric

Dirk Riehle wrote:

> We want to have exactly one EUR currency object, one USD currency
> object, etc. There should be only 150 or currency objects in use at
> any time. equals() relies on this design decision (equals is reduced
> to an identity check then).
>
> If you have a free Hibernate created instance, two EUR objects won't
> be equal if they aren't the same object.
>
Dirk, doesn't that depend on how the currency object is implemented? If
equals() compares the currency code, then two EUR objects would be
equal, whether they are the same object or not. This is how a value
object should behave. (Not actually sure about the Java Currency in this
regard. Maybe I should check.)

Ordinarily, I would think that having a single instance of each currency
would only be important as an optimization, if you had so many of them
that they hogging memory or taking too much time to instantiate. Do you
think this will often be the case? Or are there other reasons you want
to control this?

>
> Ramon Leon wrote:
>
> >Eric, I just love the way you say, "it depends".
> >
> >
> >
> Ramon, did you sneak a peek at my first draft of my posting? :-) Eric

Something like that, often when asked a question like that I'll rattle
out all the necessary context in my head that I need to explain before
giving up and just saying "it depends".  Seems your brain's better
connected to your mouth.

If it does matter, you might be able to write a Hibernate Interceptor
and implement the newInstance method to control things.   Instead of
instantiating objects itself using the default constructor, Hibernate
will invoke your code to instantiate objects, passing in the id.  If
that's what makes objects unique, then you can have newInstance always
return the same object for the same id.

(We use Interceptor.newInstance to have a dependency injection framework
instantiate entities.)

Steve

-----Original Message-----
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
Sent: Wednesday, July 13, 2005 12:38 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: Domain Models and ORM/Hibernate (was: RE:
[domaindrivendesign] Re: Repositories and Transaction Handling

Dirk Riehle wrote:

> We want to have exactly one EUR currency object, one USD currency
> object, etc. There should be only 150 or currency objects in use at
> any time. equals() relies on this design decision (equals is reduced
> to an identity check then).
>
> If you have a free Hibernate created instance, two EUR objects won't
> be equal if they aren't the same object.
>
Dirk, doesn't that depend on how the currency object is implemented? If
equals() compares the currency code, then two EUR objects would be
equal, whether they are the same object or not. This is how a value
object should behave. (Not actually sure about the Java Currency in this
regard. Maybe I should check.)

Ordinarily, I would think that having a single instance of each currency
would only be important as an optimization, if you had so many of them
that they hogging memory or taking too much time to instantiate. Do you
think this will often be the case? Or are there other reasons you want
to control this?



Yahoo! Groups Links

> Ordinarily, I would think that having a single instance of each
currency would only be important as an optimization, if
> you had so many of them that they hogging memory or taking too much
time to instantiate. Do you think this will often be
> the case? Or are there other reasons you want to control this?

I agree.  It sounds like you're coupling a domain issue (what makes two
value objects equivalent) with an optimization issue (how many distinct
instances of equivalent value objects do we have).  It seems like the
equals method should be based on logical properties, not identity.  The
method that instantiates the value objects should worry about sharing
instances.  One should be able to turn off sharing without breaking the
equals method.

I think.  But it really depends.... ;)

Steve

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dru Sellers
Sent: Wednesday, July 13, 2005 11:30 AM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

The employee object at this point acts as both a security model as well as a contact model. Ideally I would refactor this into an Employee class and a User Class that inherits from the Employee class. At least I think that is what would be "best." So it is both a CRM function in that we use it to contact people and as a security function as only employees can login.

 

Ok, I see what you are saying. I guess I either don't remember that point or never got it in the first place. Yeah I like that (method for new employees on the Company) it actually makes sense in other areas of my code too.

 

This has got to be the best par tof the list. Walking through examples with like minded people.

 

THANKS

 

dru

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
Sent: Wednesday, July 13, 2005 12:02 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] New Children Objects

So, then this is the generic subdomain of access control and security?
The entire purpose of these objects is to determine whether a particular
user has access to other features of the application? Remember, I'm a
real stickler for knowing what the domain is before modeling it! :-)

I'll assume that. But you have not really said that. If Employee is used
for *anything* else in your application, then we must know what the
domain of that application is, and what Employee has to do with it. But
I'll assume what I wrote above.

In that case, I would point to Dmitriy's post. A method on Company is
often a good place for such creation.

But please don't take this as a general answer to your original
question. There is none. Everything emerges from a deep understanding of
the domain itself.

Eric

Dru Sellers wrote:

> First: I left my DDD book in another city. I am currently working
> remote, doh! :(
> 
> The Company class represents one of our customers the AddEmployee
> method would let us add an employee to the company. Employees can then
> logon toour system. We treat the Company as the actual customer and
> the Employee as an asset/user of that company. By child object I mean
> that the Employee is a part of the Company aggregate. It makes no
> sense to talk about an employee with out also talking about the
> company that the employee works for.
> 
> The employee creation process is very simple. At a minimum it needs a
> name, if the employee is to login then a username/password as well.
> 
> Lifecycle
> If the company is deleted so is the employee. You have to have a
> company before you can have an employee.
> 
> Thanks!
> dru
>
> ------------------------------------------------------------------------
> *From:* domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] *On Behalf Of *Eric Evans
> *Sent:* Wednesday, July 13, 2005 11:30 AM
> *To:* domaindrivendesign@yahoogroups.com
> *Subject:* Re: [domaindrivendesign] New Children Objects
>
> As I always say, in these situations, you must have application
> requirements to choose a model. Is this a real example? If so, tell us
> more about the purpose of the application. If not, could you put forward
> a real case? Then we could probe enough to come up with an answer -- or,
> actually, to illustrate how to probe for the answer, which is the
> important part.
> When you say "child" object, do you mean that the Employee is part of
> the Company aggregate? We need to understand the basis of that decision.
> If this is an HR system, that would be pretty surprising. If this is a
> sales/contacts system, maybe it is logical.
> Then we need to know what is involved in making Employee objects. How
> does it fit into the lifecycle of the Company?
>
> I'd also suggest reading or revisiting the sections in my book on
> "Factories" and "Aggregates".
>
> Eric
>
>
> Dru Sellers wrote:
>
> > What is the best way to acquire a new instance of a child object. For
> > example:
> >
> > Let's say we have a parent class Company and a child class Employee.
> >
> > We also have a CompanyFactory and a CompanyRepository.
> >
> > Where do I put the method to create a new Employee? On the Company or
> > the CompanyFactory?
> >
> > Thanks,
> >
> > Dru
> >
> >
> > ------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "domaindrivendesign
> >       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
> >      
> >     *  To unsubscribe from this group, send an email to:
> >        domaindrivendesign-unsubscribe@yahoogroups.com
> >      
> <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >      
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------------
> >
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "domaindrivendesign
>       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
>       
>     *  To unsubscribe from this group, send an email to:
>        domaindrivendesign-unsubscribe@yahoogroups.com
>       <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>       
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dru Sellers
Sent: Wednesday, July 13, 2005 11:30 AM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

The employee object at this point acts as both a security model as well as a contact model. Ideally I would refactor this into an Employee class and a User Class that inherits from the Employee class. At least I think that is what would be "best." So it is both a CRM function in that we use it to contact people and as a security function as only employees can login.

 

Ok, I see what you are saying. I guess I either don't remember that point or never got it in the first place. Yeah I like that (method for new employees on the Company) it actually makes sense in other areas of my code too.

 

This has got to be the best par tof the list. Walking through examples with like minded people.

 

THANKS

 

dru

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
Sent: Wednesday, July 13, 2005 12:02 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] New Children Objects

So, then this is the generic subdomain of access control and security?
The entire purpose of these objects is to determine whether a particular
user has access to other features of the application? Remember, I'm a
real stickler for knowing what the domain is before modeling it! :-)

I'll assume that. But you have not really said that. If Employee is used
for *anything* else in your application, then we must know what the
domain of that application is, and what Employee has to do with it. But
I'll assume what I wrote above.

In that case, I would point to Dmitriy's post. A method on Company is
often a good place for such creation.

But please don't take this as a general answer to your original
question. There is none. Everything emerges from a deep understanding of
the domain itself.

Eric

Dru Sellers wrote:

> First: I left my DDD book in another city. I am currently working
> remote, doh! :(
> 
> The Company class represents one of our customers the AddEmployee
> method would let us add an employee to the company. Employees can then
> logon toour system. We treat the Company as the actual customer and
> the Employee as an asset/user of that company. By child object I mean
> that the Employee is a part of the Company aggregate. It makes no
> sense to talk about an employee with out also talking about the
> company that the employee works for.
> 
> The employee creation process is very simple. At a minimum it needs a
> name, if the employee is to login then a username/password as well.
> 
> Lifecycle
> If the company is deleted so is the employee. You have to have a
> company before you can have an employee.
> 
> Thanks!
> dru
>
> ------------------------------------------------------------------------
> *From:* domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] *On Behalf Of *Eric Evans
> *Sent:* Wednesday, July 13, 2005 11:30 AM
> *To:* domaindrivendesign@yahoogroups.com
> *Subject:* Re: [domaindrivendesign] New Children Objects
>
> As I always say, in these situations, you must have application
> requirements to choose a model. Is this a real example? If so, tell us
> more about the purpose of the application. If not, could you put forward
> a real case? Then we could probe enough to come up with an answer -- or,
> actually, to illustrate how to probe for the answer, which is the
> important part.
> When you say "child" object, do you mean that the Employee is part of
> the Company aggregate? We need to understand the basis of that decision.
> If this is an HR system, that would be pretty surprising. If this is a
> sales/contacts system, maybe it is logical.
> Then we need to know what is involved in making Employee objects. How
> does it fit into the lifecycle of the Company?
>
> I'd also suggest reading or revisiting the sections in my book on
> "Factories" and "Aggregates".
>
> Eric
>
>
> Dru Sellers wrote:
>
> > What is the best way to acquire a new instance of a child object. For
> > example:
> >
> > Let's say we have a parent class Company and a child class Employee.
> >
> > We also have a CompanyFactory and a CompanyRepository.
> >
> > Where do I put the method to create a new Employee? On the Company or
> > the CompanyFactory?
> >
> > Thanks,
> >
> > Dru
> >
> >
> > ------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "domaindrivendesign
> >       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
> >      
> >     *  To unsubscribe from this group, send an email to:
> >        domaindrivendesign-unsubscribe@yahoogroups.com
> >      
> <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >      
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------------
> >
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "domaindrivendesign
>       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
>       
>     *  To unsubscribe from this group, send an email to:
>        domaindrivendesign-unsubscribe@yahoogroups.com
>       <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>       
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

party pattern?

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Ramon Leon
Sent: Wednesday, July 13, 2005 1:55 PM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

I suggest you read up on the party pattern, inheritance probably isn't the solution here.  User is likely a role an employee can play, and so is party, where you'd keep the contact info.

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dru Sellers
Sent: Wednesday, July 13, 2005 11:30 AM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

The employee object at this point acts as both a security model as well as a contact model. Ideally I would refactor this into an Employee class and a User Class that inherits from the Employee class. At least I think that is what would be "best." So it is both a CRM function in that we use it to contact people and as a security function as only employees can login.

 

Ok, I see what you are saying. I guess I either don't remember that point or never got it in the first place. Yeah I like that (method for new employees on the Company) it actually makes sense in other areas of my code too.

 

This has got to be the best par tof the list. Walking through examples with like minded people.

 

THANKS

 

dru

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
Sent: Wednesday, July 13, 2005 12:02 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] New Children Objects

So, then this is the generic subdomain of access control and security?
The entire purpose of these objects is to determine whether a particular
user has access to other features of the application? Remember, I'm a
real stickler for knowing what the domain is before modeling it! :-)

I'll assume that. But you have not really said that. If Employee is used
for *anything* else in your application, then we must know what the
domain of that application is, and what Employee has to do with it. But
I'll assume what I wrote above.

In that case, I would point to Dmitriy's post. A method on Company is
often a good place for such creation.

But please don't take this as a general answer to your original
question. There is none. Everything emerges from a deep understanding of
the domain itself.

Eric

Dru Sellers wrote:

> First: I left my DDD book in another city. I am currently working
> remote, doh! :(
> 
> The Company class represents one of our customers the AddEmployee
> method would let us add an employee to the company. Employees can then
> logon toour system. We treat the Company as the actual customer and
> the Employee as an asset/user of that company. By child object I mean
> that the Employee is a part of the Company aggregate. It makes no
> sense to talk about an employee with out also talking about the
> company that the employee works for.
> 
> The employee creation process is very simple. At a minimum it needs a
> name, if the employee is to login then a username/password as well.
> 
> Lifecycle
> If the company is deleted so is the employee. You have to have a
> company before you can have an employee.
> 
> Thanks!
> dru
>
> ------------------------------------------------------------------------
> *From:* domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] *On Behalf Of *Eric Evans
> *Sent:* Wednesday, July 13, 2005 11:30 AM
> *To:* domaindrivendesign@yahoogroups.com
> *Subject:* Re: [domaindrivendesign] New Children Objects
>
> As I always say, in these situations, you must have application
> requirements to choose a model. Is this a real example? If so, tell us
> more about the purpose of the application. If not, could you put forward
> a real case? Then we could probe enough to come up with an answer -- or,
> actually, to illustrate how to probe for the answer, which is the
> important part.
> When you say "child" object, do you mean that the Employee is part of
> the Company aggregate? We need to understand the basis of that decision.
> If this is an HR system, that would be pretty surprising. If this is a
> sales/contacts system, maybe it is logical.
> Then we need to know what is involved in making Employee objects. How
> does it fit into the lifecycle of the Company?
>
> I'd also suggest reading or revisiting the sections in my book on
> "Factories" and "Aggregates".
>
> Eric
>
>
> Dru Sellers wrote:
>
> > What is the best way to acquire a new instance of a child object. For
> > example:
> >
> > Let's say we have a parent class Company and a child class Employee.
> >
> > We also have a CompanyFactory and a CompanyRepository.
> >
> > Where do I put the method to create a new Employee? On the Company or
> > the CompanyFactory?
> >
> > Thanks,
> >
> > Dru
> >
> >
> > ------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "domaindrivendesign
> >       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
> >      
> >     *  To unsubscribe from this group, send an email to:
> >        domaindrivendesign-unsubscribe@yahoogroups.com
> >      
> <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >      
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------------
> >
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "domaindrivendesign
>       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
>       
>     *  To unsubscribe from this group, send an email to:
>        domaindrivendesign-unsubscribe@yahoogroups.com
>       <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>       
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

party pattern?

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Ramon Leon
Sent: Wednesday, July 13, 2005 1:55 PM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

I suggest you read up on the party pattern, inheritance probably isn't the solution here.  User is likely a role an employee can play, and so is party, where you'd keep the contact info.

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dru Sellers
Sent: Wednesday, July 13, 2005 11:30 AM
To: domaindrivendesign@yahoogroups.com
Subject: RE: [domaindrivendesign] New Children Objects

The employee object at this point acts as both a security model as well as a contact model. Ideally I would refactor this into an Employee class and a User Class that inherits from the Employee class. At least I think that is what would be "best." So it is both a CRM function in that we use it to contact people and as a security function as only employees can login.

 

Ok, I see what you are saying. I guess I either don't remember that point or never got it in the first place. Yeah I like that (method for new employees on the Company) it actually makes sense in other areas of my code too.

 

This has got to be the best par tof the list. Walking through examples with like minded people.

 

THANKS

 

dru

---

From: domaindrivendesign@yahoogroups.com [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
Sent: Wednesday, July 13, 2005 12:02 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] New Children Objects

So, then this is the generic subdomain of access control and security?
The entire purpose of these objects is to determine whether a particular
user has access to other features of the application? Remember, I'm a
real stickler for knowing what the domain is before modeling it! :-)

I'll assume that. But you have not really said that. If Employee is used
for *anything* else in your application, then we must know what the
domain of that application is, and what Employee has to do with it. But
I'll assume what I wrote above.

In that case, I would point to Dmitriy's post. A method on Company is
often a good place for such creation.

But please don't take this as a general answer to your original
question. There is none. Everything emerges from a deep understanding of
the domain itself.

Eric

Dru Sellers wrote:

> First: I left my DDD book in another city. I am currently working
> remote, doh! :(
> 
> The Company class represents one of our customers the AddEmployee
> method would let us add an employee to the company. Employees can then
> logon toour system. We treat the Company as the actual customer and
> the Employee as an asset/user of that company. By child object I mean
> that the Employee is a part of the Company aggregate. It makes no
> sense to talk about an employee with out also talking about the
> company that the employee works for.
> 
> The employee creation process is very simple. At a minimum it needs a
> name, if the employee is to login then a username/password as well.
> 
> Lifecycle
> If the company is deleted so is the employee. You have to have a
> company before you can have an employee.
> 
> Thanks!
> dru
>
> ------------------------------------------------------------------------
> *From:* domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] *On Behalf Of *Eric Evans
> *Sent:* Wednesday, July 13, 2005 11:30 AM
> *To:* domaindrivendesign@yahoogroups.com
> *Subject:* Re: [domaindrivendesign] New Children Objects
>
> As I always say, in these situations, you must have application
> requirements to choose a model. Is this a real example? If so, tell us
> more about the purpose of the application. If not, could you put forward
> a real case? Then we could probe enough to come up with an answer -- or,
> actually, to illustrate how to probe for the answer, which is the
> important part.
> When you say "child" object, do you mean that the Employee is part of
> the Company aggregate? We need to understand the basis of that decision.
> If this is an HR system, that would be pretty surprising. If this is a
> sales/contacts system, maybe it is logical.
> Then we need to know what is involved in making Employee objects. How
> does it fit into the lifecycle of the Company?
>
> I'd also suggest reading or revisiting the sections in my book on
> "Factories" and "Aggregates".
>
> Eric
>
>
> Dru Sellers wrote:
>
> > What is the best way to acquire a new instance of a child object. For
> > example:
> >
> > Let's say we have a parent class Company and a child class Employee.
> >
> > We also have a CompanyFactory and a CompanyRepository.
> >
> > Where do I put the method to create a new Employee? On the Company or
> > the CompanyFactory?
> >
> > Thanks,
> >
> > Dru
> >
> >
> > ------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "domaindrivendesign
> >       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
> >      
> >     *  To unsubscribe from this group, send an email to:
> >        domaindrivendesign-unsubscribe@yahoogroups.com
> >      
> <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >      
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > ------------------------------------------------------------------------
> >
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "domaindrivendesign
>       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
>       
>     *  To unsubscribe from this group, send an email to:
>        domaindrivendesign-unsubscribe@yahoogroups.com
>       <mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>       
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

> Dirk wrote:
>Hibernate lets you specify value objects as components, but then you
>have to repeat the component structure any time you use a specific
>value object. For example, in an Account class, a balance attribute
>might be mapped like this:
>
> <component name="balance" class="org.jvalue.finance.Money">
>  <property name="amount" access="field" column="BALANCE"/>
>  <component name="currency" access="field"
class="org.jvalue.finance.Currency">
>   <property name="code" access="field" column="CURRENCY"/>
>  </component>
> </component>
>
> If you use Money objects some other place, you have to repeat that
> same definition in that other class mapping definition. So much about
> redundancy.

Are you using Money specifically as a balance property mapped to BALANCE
and CURRENCY columns in many objects? If so, then you might consider
including the Money component definition as a XML entity. If not, then
you really don't have that much duplication/redundancy.

> Then I see Hibernate lets you specify classes as value objects, called
> user types. Unfortunately, you have to implement UserType or
> CompositeUserType. For us, this is out of the question, as we can't
> change/reimplement/extend our library that way. Wasn't a good OR
> Mapper supposed to be non-invasive?

Have you looked at the example at http://www.hibernate.org/172.html?
It shows how to use a UserType adapter to persist an immutable
value without extending it.

> 2. Field access. Hibernate wants us to use getters and setter for
> loading/saving objects. This gets in the way of domain semantics, for
> example some of our (legacy) code uses old-style assertions, for
> example:
> ...
> In Hibernate you can get around that by declaring access to a field as
> access="field" which avoids using getters and setters but goes to the
> field directly. But then you won't get the benefit of the setter where
> necessary. For example, some of our value objects are immutable shared
> objects (Currency) and having an anonymously created instance floating
> around breaks that model. Going back to getter/setter field access
> doesn't cut it as the issue is independent of this.

I don't understand some of the issues here. Are you saying that you
have a specific mapped property that sometimes should be set directly
on a field and other times should be set using a setter method?

There are a couple of ways you could implement shared value
objects. The user type or component user type adapter should use
some form of a registry to locate, rather than create, the user
type instances to provide to Hibernate when it loads a persistent
object.

It's been a few years ago, but I implemented an extended Hibernate
Persister that used a Spring bean context to create object instances
that Hibernate would then map to persistent data. This isn't exactly
what you're looking for, but it was interesting because it allowed
us to also initialize shared, non-persistent data (often implemented
as so-called "singletons") when loading a persistent object.

Steve

Dirk,

Does the example at http://www.hibernate.org/172.html do what
you want? It's mapping shared, immutable instances using a
user type adapter without extending the shared class.

Steve
________________________________________
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
Sent: Wednesday, July 13, 2005 12:12 PM
To: domaindrivendesign@yahoogroups.com
Subject: RE: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign]
Re: Repositories and Transaction Handling

We want to have exactly one EUR currency object, one USD currency object,
etc. There should be only 150 or currency objects in use at any time.
equals() relies on this design decision (equals is reduced to an identity
check then).

If you have a free Hibernate created instance, two EUR objects won't be
equal if they aren't the same object.

In an older app we used the framework this made quite a performance
difference. (Not so in the current one.) Today it is not as critical any
longer for us, but it is just how the framework is built. You can switch
on/off sharing of value objects.

Dirk



At 13.07.2005, Molitor, Stephen L wrote:

Dirk (not Roni!)
 
Sorry, didn't read your post carefully enough.  Regarding #2, I didn't quite
understand this bit:
 
> In Hibernate you can get around that by declaring access to a field as
access="field" which avoids using getters and setters but goes to the field
> directly. But then you won't get the benefit of the setter where
necessary. For example, some of our value objects are immutable shared
objects > > (Currency) and having an anonymously created instance floating
around breaks that model. Going back to getter/setter field access doesn't
cut it
> as the issue is independent of this.
 
If the objects are immutable, why does it matter if they are shared or not? 
How does having a Hibernate created instance floating around break the
model?
 
Steve

________________________________________
From: domaindrivendesign@yahoogroups.com [
mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
Sent: Wednesday, July 13, 2005 4:23 AM
To: domaindrivendesign@yahoogroups.com
Subject: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re:
Repositories and Transaction Handling

Hi all,

we started using Hibernate about a week ago, and even though I think it is
probably the best of the ORM tools available, it does get in the way with
(a) proper domain modeling and (b) separating domain models from persistence
layers.

I thought I'd describe the main issues I'm having right now---maybe someone
knows a better solution or at least finds this interesting.

1. Value Objects. We have a whole library of value objects (an earlier
version can be found on www.jvalue.org) and so we would like to map them
into columns within the enclosing entity object's table.

Hibernate lets you specify value objects as components, but then you have to
repeat the component structure any time you use a specific value object. For
example, in an Account class, a balance attribute might be mapped like this:

<component name="balance" class="org.jvalue.finance.Money">
         <property name="amount" access="field" column="BALANCE"/>
         <component name="currency" access="field"
class="org.jvalue.finance.Currency">
                 <property name="code" access="field" column="CURRENCY"/>
         </component>
</component>

If you use Money objects some other place, you have to repeat that same
definition in that other class mapping definition. So much about redundancy.

Then I see Hibernate lets you specify classes as value objects, called user
types. Unfortunately, you have to implement UserType or CompositeUserType.
For us, this is out of the question, as we can't change/reimplement/extend
our library that way. Wasn't a good OR Mapper supposed to be non-invasive?

2. Field access. Hibernate wants us to use getters and setter for
loading/saving objects. This gets in the way of domain semantics, for
example some of our (legacy) code uses old-style assertions, for example:

class Posting...

        public void setValidityDate(JDate date) {
                 // FIXME: assertIsNotSealed();
                 validityDate = JDate.getValue(date.asMilliseconds());
        }
}

assertIsNotSealed() throws an exception if this posting to a book had been
carried out, hence sealed, and is supposed not to be touched. That behavior
is part of the domain model for sure!

In Hibernate you can get around that by declaring access to a field as
access="field" which avoids using getters and setters but goes to the field
directly. But then you won't get the benefit of the setter where necessary.
For example, some of our value objects are immutable shared objects
(Currency) and having an anonymously created instance floating around breaks
that model. Going back to getter/setter field access doesn't cut it as the
issue is independent of this.

Anyway, long post, rather frustratedly, but still interesting, I hope.

Dirk


Interested in wikis? Please go to http://www.wikisym.org!
Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
Dirk Riehle | +49 172 184 8755 | http://www.riehle.org


        




At 12.07.2005, Billy McCafferty wrote:

Theres a great example of separating the transactional layer in Chapter 8
of Hibernate in Action by Christian Bauer and Gavin King.
 
Billy McCafferty
 
 
-----Original Message-----
From: domaindrivendesign@yahoogroups.com [
mailto:domaindrivendesign@yahoogroups.com] On Behalf Of andrew_raphael_small
Sent: Saturday, July 09, 2005 1:22 PM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Re: Repositories and Transaction Handling
 
--- In domaindrivendesign@yahoogroups.com, Rex Madden
<rexmadden@g...> wrote:
> Any OR mapping tool will have several options for handling
transactions. For
> example, in Hibernate, the simplest method is to pass a session to
your
> repository which is opened at the beginning of a request, and then
flushed
> and closed at the end of a request (assuming you are talking about
a web
> app). You can use a ServletFilter to do the opening and closing.
>  Of course, there are more sophisticated patterns for complicated
scenarios,
> but that's a good way to start.
>
>
> --
> Rex Madden

I would be very interested to learn about those more sophisticated
patterns.  Do you know some references that I can look at?  I want to
set up our application to use the simple pattern you describe but I
also want to be ready to address the complicated scenarios that we
may encounter.

Andrew Small



<?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?----
HM ADS ?>
________________________________________
YAHOO! GROUPS LINKS
•  Visit your group " domaindrivendesign" on the web.
•  To unsubscribe from this group, send an email to:
•   domaindrivendesign-unsubscribe@yahoogroups.com
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

________________________________________
<?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?----
HM ADS ?>
________________________________________
YAHOO! GROUPS LINKS
•  Visit your group " domaindrivendesign" on the web.
•  
•  To unsubscribe from this group, send an email to:
•   domaindrivendesign-unsubscribe@yahoogroups.com
•  
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

________________________________________
Interested in wikis? Please go to http://www.wikisym.org!
Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
Dirk Riehle | +49 172 184 8755 | http://www.riehle.org

________________________________________
YAHOO! GROUPS LINKS

•  Visit your group "domaindrivendesign" on the web.
 
•  To unsubscribe from this group, send an email to:
 domaindrivendesign-unsubscribe@yahoogroups.com
 
•  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

________________________________________

Hi,

I've been reading Domain Driven Design with great interest.  For the
past year or so I have been using J2EE with Spring, with an
architecture style that is very similar to DDD's, i.e. with layers:

   presentation
   application/service
   DAO

The application layer contains services that generally obtain and
manipulate domain entities.

I try to put as much domain logic as possible into the domain layer.
However, as I currently have it the domain layer has no knowledge of
DAOs (I read DAO == Repository in DDD terminology) -- only the
application layer can access DAOs.  So, often a lot of domain logic
slips up into the application layer.

Having read in DDD that repositories can be part of the domain layer
after all, I am rethinking my architectural approach.

The main issue I have is: how do entities get hold of repositories?

The easy option is to use the Service Locator pattern, i.e.
dependency lookup.  Is there a nice way to do it with dependency
injection?

Please let me know if I am confused in equating DAOs with
repositories.

Regards

John Hurst
Wellington, New Zealand

On 7/13/05, jbhurst2003 <jbhurst@...> wrote:
> Hi,
>
> I've been reading Domain Driven Design with great interest.  For the
> past year or so I have been using J2EE with Spring, with an
> architecture style that is very similar to DDD's, i.e. with layers:
>
>  presentation
>  application/service
>  DAO
>
> The application layer contains services that generally obtain and
> manipulate domain entities.
>
> I try to put as much domain logic as possible into the domain layer.
> However, as I currently have it the domain layer has no knowledge of
> DAOs (I read DAO == Repository in DDD terminology) -- only the
> application layer can access DAOs.  So, often a lot of domain logic
> slips up into the application layer.
>
> Having read in DDD that repositories can be part of the domain layer
> after all, I am rethinking my architectural approach.
>
> The main issue I have is: how do entities get hold of repositories?
>
> The easy option is to use the Service Locator pattern, i.e.
> dependency lookup.  Is there a nice way to do it with dependency
> injection?
>

Hibernate let's you inject into entities. Some other persistence
frameworks might.
But the easiest portable way for an entity access a repository is to
pass the repository or a service locator as a method  parameter.
This topic has been discussed a few times.
One good thread is titled "Should repositories be singletons?" from
about a year ago.

> Please let me know if I am confused in equating DAOs with
> repositories.
>

I think it depends on who you talk to.
I think I have seen emails suggesting that repositories call DAOs.
I think they are the approximately the same - at least at a code level
- even though their intent is perhaps different.

Chris

--
Enterprise POJOs blog - http://chris-richardson.blog-city.com
Author, POJOs in Action - http://www.manning.com/crichardson

Are you using Money specifically as a balance property mapped to BALANCE
and CURRENCY columns in many objects? If so, then you might consider
including the Money component definition as a XML entity. If not, then
you really don't have that much duplication/redundancy.

> Then I see Hibernate lets you specify classes as value objects, called
> user types. Unfortunately, you have to implement UserType or
> CompositeUserType. For us, this is out of the question, as we can't
> change/reimplement/extend our library that way. Wasn't a good OR
> Mapper supposed to be non-invasive?

Have you looked at the example at http://www.hibernate.org/172.html?
It shows how to use a UserType adapter to persist an immutable
value without extending it.

> In Hibernate you can get around that by declaring access to a field as
> access="field" which avoids using getters and setters but goes to the
> field directly. But then you won't get the benefit of the setter where
> necessary. For example, some of our value objects are immutable shared
> objects (Currency) and having an anonymously created instance floating
> around breaks that model. Going back to getter/setter field access
> doesn't cut it as the issue is independent of this.

I don't understand some of the issues here. Are you saying that you
have a specific mapped property that sometimes should be set directly
on a field and other times should be set using a setter method?

> > We want to have exactly one EUR currency object, one USD currency
> > object, etc. There should be only 150 or currency objects in use at
> > any time. equals() relies on this design decision (equals is reduced
> > to an identity check then).
> >
> > If you have a free Hibernate created instance, two EUR objects won't
> > be equal if they aren't the same object.
> >
>Dirk, doesn't that depend on how the currency object is implemented? If
>equals() compares the currency code, then two EUR objects would be
>equal, whether they are the same object or not. This is how a value
>object should behave. (Not actually sure about the Java Currency in this
>regard. Maybe I should check.)

Yes, it is an optimization. Using identity to check for equality doesn't
violate value semantics, as long as you can guarantee that there is only
one instance of a specific value.

The point is: JValue is a framework, so we can't optimize for one specific
use but rather let users decide. The actual identity check isn't even done
in Currency but up in the hierarchy, in AbstractValue. equals(Object other)
looks something like this: return (other != null) || (other == this) ||
(!type.isShared() && hasEquivalentType(other) && doEquals(other)); doEquals
does the traditional field by field comparison and is implemented by
subclasses of AbstractValue (like Currency).

Once you do a full framework approach, it can get complicated.
type.isShared() tells you whether this value type is in shared mode or not.
hasEquivalentType() checks whether different implementations of the same
value type are considered equivalent. Not so much an issue with Currency,
but we used structured names a lot (www.ddd.org is a structured name with
three components and the delimiter '.'), and had different implementations
(Whole name in a single string, name components pre-parsed in an array or
list.)

The curse of trying to do it right for all possible uses :-) But fun.

Dirk

PS: Yes, it was all necessary. JValue was used in a high-performance
infrastructure as well as a low-performing simulation environment at my
prior company (SKYVA). The simulation environment was part of a UML IDE
that let you introduce new value types (UML datatypes) at runtime so we
needed to allow for runtime creation of value types which meant a whole
explicit modeling level for value types.

PPS: I'm just reading up on Domain-Specific Languages or "language-oriented
programming". If you want to do something like this, you'll end up doing
something like JValue. So I'm sure JetBrains, MS, and Intentional Software
have gone through the same problems.



Interested in wikis? Please go to http://www.wikisym.org!
Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
Dirk Riehle | +49 172 184 8755 | http://www.riehle.org

_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com

This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners. Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited. If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation.

_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com

This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners. Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited. If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation.

We have as a goal to have as much as possible of our domain objects be
serializable, so that we can use them as DTOs as well. In Java, I
think we will have to jump through some pretty ugly hoops with custom
serialization. Does anyone have similiar experiences?

Should we:
* Drop the Serializable requirement, and develop a separate DTO model
where needed? (This will require extra code)
* Avoid the dependencies on services, repositories, etc? (This will
make our domain model more anemic)
* Do the black magic serialization thingie? (Requires lookups of
singleton-like services during deserialization)

Regarding Hibernate and DAOs: We are contemplating putting in heavier
use of Repositories from our domain objects, even though we are mostly
using Hibernate. In the cases where we have to call external services,
this may prove to substantially improve our domain model.


~Johannes

On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
>
> Our entities often have several dependencies, besides the usual dependencies
> on things that are part of the aggregate (child entities and value objects).
>  Most of the time, *on our project* (YMMV), they are not *external*
> resources, but rather POJO policy objects (calculator or formula objects,
> validator policies, etc.).   If it makes things easier to test, we might
> dependency inject those policies into the entities.
>
> We're using an O/R mapper (Hibernate), so our entities don't usually have a
> dependency on DAO's.  But sometimes they do -- for example it might be more
> efficient to return a filtered collection of the entity using a query (or
> Hibernate filter) as opposed to filtering in memory in code, and we'll
> encapsulate that in a DAO / repository.  And we'll usually dependency inject
> those into the entities.  (Although I think you can now map such a filtered
> collection in Hibernate, which would remove the need for some of these
> DAO's.)
>
> Steve
>
>
>  ________________________________
>  From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of
> Jeff Lowe
> Sent: Monday, July 18, 2005 10:52 AM
> To: domaindrivendesign@yahoogroups.com
> Subject: [domaindrivendesign] Entity Dependencies
>
>
>
> >> Do you inject dependencies into Entities often?  It seems like something
> I try to avoid, but I may be wrong.
>
> I'm not sure if you're referring to the specific method of providing an
> Entity with its dependencies (i.e. dependency injection), or the concept of
> an Entity having external dependencies.  Assuming the latter, this question
> suggests an issue that I keep encountering in my own development efforts.
>
> I find that in order to have a domain model that is rich in behavior (as
> opposed to the AnemicDomainModel anti-pattern -
> http://www.martinfowler.com/bliki/AnemicDomainModel.html),
> Entities sometimes depend on external resources (e.g. database access via a
> DAO, message queues, web services, etc.).  Therefore I would think that
> having an Entity with external dependencies would be a pretty common
> requirement for implementing non-trivial behavior.  I'm curious what other
> folks' experience is.
>
> Thanks,
> -Jeff
>
>
>
>  ________________________________
>  From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of
> Rex Madden
> Sent: Wednesday, July 13, 2005 2:39 PM
> To: domaindrivendesign@yahoogroups.com
> Subject: Re: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign]
> Re: Repositories and Transaction Handling
>
>
> Do you inject dependencies into Entities often?  It seems like something I
> try to avoid, but I may be wrong.
>
>
> On 7/13/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
> >
> >
> > (We use Interceptor.newInstance to have a dependency injection framework
> > instantiate entities.)
> >
> > Steve
> >
> > -----Original Message-----
> > From: domaindrivendesign@yahoogroups.com
> > [mailto:domaindrivendesign@yahoogroups.com ] On Behalf Of
> Eric Evans
> > Sent: Wednesday, July 13, 2005 12:38 PM
> > To: domaindrivendesign@yahoogroups.com
> > Subject: Re: Domain Models and ORM/Hibernate (was: RE:
> > [domaindrivendesign] Re: Repositories and Transaction Handling
> >
> > Dirk Riehle wrote:
> >
> > > We want to have exactly one EUR currency object, one USD currency
> > > object, etc. There should be only 150 or currency objects in use at
> > > any time. equals() relies on this design decision (equals is reduced
> > > to an identity check then).
> > >
> > > If you have a free Hibernate created instance, two EUR objects won't
> > > be equal if they aren't the same object.
> > >
> > Dirk, doesn't that depend on how the currency object is implemented? If
> > equals() compares the currency code, then two EUR objects would be
> > equal, whether they are the same object or not. This is how a value
> > object should behave. (Not actually sure about the Java Currency in this
> > regard. Maybe I should check.)
> >
> > Ordinarily, I would think that having a single instance of each currency
> > would only be important as an optimization, if you had so many of them
> > that they hogging memory or taking too much time to instantiate. Do you
> > think this will often be the case? Or are there other reasons you want
> > to control this?
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Rex Madden
> Director of Technology
> Cyrus Innovation
> IT Consulting and Agile Software Development
> New York City, New York
>
> http://www.cyrusinnovation.com
> rmadden@...
>
> _______________
> Siebel
> IT'S ALL ABOUT THE CUSTOMER
> Visit www.siebel.com
>
> This e-mail message is for the sole use of the intended recipient(s) and
> contains confidential and/or privileged information belonging to Siebel
> Systems, Inc. or its customers or partners. Any unauthorized review, use,
> copying, disclosure or distribution of this message is strictly prohibited.
> If you are not an intended recipient of this message, please contact the
> sender by reply e-mail and destroy all soft and hard copies of the message
> and any attachments. Thank you for your cooperation.
>
>
>
>  SPONSORED LINKS
>  Computer backup software Computer help desk software Computer monitoring
> software
>  Computer security software Computer service software Designing software
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "domaindrivendesign" on the web.
>
>  To unsubscribe from this group, send an email to:
>  domaindrivendesign-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>

This brings up several interesting issues.

1.  I would not try to make your domain model double as DTO's.  Not for
the technical headaches, but for the maintenance ones.  The stuff a
client wants in a DTO and the stuff an entity requires needs to be able
to vary independently.  You'll either end up dumbing down your domain
model, or fatting up your DTO's.  (And remember, if you don't have
remote clients, you don't need DTO's!)

2.  I'm a little squeamish about having entities depend on external
services.  POJO policies, fine.  It seems to me that entities should
have very fine grained relationships within an aggregate, and very
minimal dependencies outside that aggregate.  If an entity depends on a
remote service, that drives you towards a much coarser grained
interface.   My instinct would be to avoid those kinds of dependencies
within entities, and instead have the service layer pass in the
information from the external service.  Not sure though.

Steve

-----Original Message-----
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Johannes
Brodwall
Sent: Monday, July 18, 2005 11:38 AM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] Entity Dependencies

We have as a goal to have as much as possible of our domain objects be
serializable, so that we can use them as DTOs as well. In Java, I think
we will have to jump through some pretty ugly hoops with custom
serialization. Does anyone have similiar experiences?

Should we:
* Drop the Serializable requirement, and develop a separate DTO model
where needed? (This will require extra code)
* Avoid the dependencies on services, repositories, etc? (This will make
our domain model more anemic)
* Do the black magic serialization thingie? (Requires lookups of
singleton-like services during deserialization)

Regarding Hibernate and DAOs: We are contemplating putting in heavier
use of Repositories from our domain objects, even though we are mostly
using Hibernate. In the cases where we have to call external services,
this may prove to substantially improve our domain model.


~Johannes

On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
>
> Our entities often have several dependencies, besides the usual
> dependencies on things that are part of the aggregate (child entities
and value objects).
>  Most of the time, *on our project* (YMMV), they are not *external*
> resources, but rather POJO policy objects (calculator or formula
objects,
> validator policies, etc.).   If it makes things easier to test, we
might
> dependency inject those policies into the entities.
>
> We're using an O/R mapper (Hibernate), so our entities don't usually
> have a dependency on DAO's.  But sometimes they do -- for example it
> might be more efficient to return a filtered collection of the entity
> using a query (or Hibernate filter) as opposed to filtering in memory
> in code, and we'll encapsulate that in a DAO / repository.  And we'll
> usually dependency inject those into the entities.  (Although I think
> you can now map such a filtered collection in Hibernate, which would
> remove the need for some of these
> DAO's.)
>
> Steve
>
>
>  ________________________________
>  From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jeff Lowe
> Sent: Monday, July 18, 2005 10:52 AM
> To: domaindrivendesign@yahoogroups.com
> Subject: [domaindrivendesign] Entity Dependencies
>
>
>
> >> Do you inject dependencies into Entities often?  It seems like
> >> something
> I try to avoid, but I may be wrong.
>
> I'm not sure if you're referring to the specific method of providing
> an Entity with its dependencies (i.e. dependency injection), or the
> concept of an Entity having external dependencies.  Assuming the
> latter, this question suggests an issue that I keep encountering in my
own development efforts.
>
> I find that in order to have a domain model that is rich in behavior
> (as opposed to the AnemicDomainModel anti-pattern -
> http://www.martinfowler.com/bliki/AnemicDomainModel.html),
> Entities sometimes depend on external resources (e.g. database access
> via a DAO, message queues, web services, etc.).  Therefore I would
> think that having an Entity with external dependencies would be a
> pretty common requirement for implementing non-trivial behavior.  I'm
> curious what other folks' experience is.
>
> Thanks,
> -Jeff
>
>
>
>  ________________________________
>  From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Rex Madden
> Sent: Wednesday, July 13, 2005 2:39 PM
> To: domaindrivendesign@yahoogroups.com
> Subject: Re: Domain Models and ORM/Hibernate (was: RE:
> [domaindrivendesign]
> Re: Repositories and Transaction Handling
>
>
> Do you inject dependencies into Entities often?  It seems like
> something I try to avoid, but I may be wrong.
>
>
> On 7/13/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
> >
> >
> > (We use Interceptor.newInstance to have a dependency injection
> > framework instantiate entities.)
> >
> > Steve
> >
> > -----Original Message-----
> > From: domaindrivendesign@yahoogroups.com
> > [mailto:domaindrivendesign@yahoogroups.com ] On Behalf Of
> Eric Evans
> > Sent: Wednesday, July 13, 2005 12:38 PM
> > To: domaindrivendesign@yahoogroups.com
> > Subject: Re: Domain Models and ORM/Hibernate (was: RE:
> > [domaindrivendesign] Re: Repositories and Transaction Handling
> >
> > Dirk Riehle wrote:
> >
> > > We want to have exactly one EUR currency object, one USD currency
> > > object, etc. There should be only 150 or currency objects in use
> > > at any time. equals() relies on this design decision (equals is
> > > reduced to an identity check then).
> > >
> > > If you have a free Hibernate created instance, two EUR objects
> > > won't be equal if they aren't the same object.
> > >
> > Dirk, doesn't that depend on how the currency object is implemented?

> > If
> > equals() compares the currency code, then two EUR objects would be
> > equal, whether they are the same object or not. This is how a value
> > object should behave. (Not actually sure about the Java Currency in
> > this regard. Maybe I should check.)
> >
> > Ordinarily, I would think that having a single instance of each
> > currency would only be important as an optimization, if you had so
> > many of them that they hogging memory or taking too much time to
> > instantiate. Do you think this will often be the case? Or are there
> > other reasons you want to control this?
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Rex Madden
> Director of Technology
> Cyrus Innovation
> IT Consulting and Agile Software Development New York City, New York
>
> http://www.cyrusinnovation.com
> rmadden@...
>
> _______________
> Siebel
> IT'S ALL ABOUT THE CUSTOMER
> Visit www.siebel.com
>
> This e-mail message is for the sole use of the intended recipient(s)
> and contains confidential and/or privileged information belonging to
> Siebel Systems, Inc. or its customers or partners. Any unauthorized
> review, use, copying, disclosure or distribution of this message is
strictly prohibited.
> If you are not an intended recipient of this message, please contact
> the sender by reply e-mail and destroy all soft and hard copies of the

> message and any attachments. Thank you for your cooperation.
>
>
>
>  SPONSORED LINKS
>  Computer backup software Computer help desk software Computer
> monitoring software  Computer security software Computer service
> software Designing software
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "domaindrivendesign" on the web.
>
>  To unsubscribe from this group, send an email to:
>  domaindrivendesign-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>



Yahoo! Groups Links

On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
> This brings up several interesting issues.
>
> 1.  I would not try to make your domain model double as DTO's.  Not for
> the technical headaches, but for the maintenance ones.  The stuff a
> client wants in a DTO and the stuff an entity requires needs to be able
> to vary independently.  You'll either end up dumbing down your domain
> model, or fatting up your DTO's.  (And remember, if you don't have
> remote clients, you don't need DTO's!)
>

I am leaning towards this interpretation as well. We come from a Spif
(http://spif.sourceforge.net) legacy, and Spif is very much the
mindchild of the idea that we could grow a domain model from DTOs,
much to counter the tendencies a few years ago. Maybe it is time to
reconsider this policy.

>
> 2.  I'm a little squeamish about having entities depend on external
> services.  POJO policies, fine.  It seems to me that entities should
> have very fine grained relationships within an aggregate, and very
> minimal dependencies outside that aggregate.  If an entity depends on a
> remote service, that drives you towards a much coarser grained
> interface.   My instinct would be to avoid those kinds of dependencies
> within entities, and instead have the service layer pass in the
> information from the external service.  Not sure though.
>

I'll tell you the specific example. Let me know if you think it is
inappropriate. Our domain is mediating payments between different
banks. When we process a payment, we need to send it to the server of
the bank owning the debitor account to authorize the payment (reserve
money). The debit account number can determine the destination bank
server. This is a core part of our domain, but most of internals are
hidden inside a different (remote) service developed by another
(in-house, but distant) team.

So what I am contemplating is to basically let
payment.getDebitAccount().getIssuingBank().getServer() (with most of
the train wreck hidden, of course) transparently look up the "Issuing
bank" relationship through the remote interface. This is implemented
as a repository.

So in other words, part of our domain model is controlled by another
application, but we want to simulate coherent domain model to be able
to implement the business logic inside the domain model.

What do you think?


~Johannes

>> So what I am contemplating is to basically let
payment.getDebitAccount().getIssuingBank().getServer() (with most of the
train wreck hidden, of course) transparently look up the "Issuing bank"
relationship through the remote interface. This is implemented as a
repository.

It appears that the complex lookup of the IssuingBank (i.e. the
trainwreck) is encapsulated in an IssuingBank Repository.  Then the
IssuingBank Entity encapsulates the communication with a remote server
via a remote interface or service.  I've also implemented Entities like
this, where they have dependencies on remote interfaces or services.  I
use dependency injection (i.e. Spring) to provide those at runtime.





-----Original Message-----
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Johannes
Brodwall
Sent: Monday, July 18, 2005 2:24 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] Entity Dependencies

On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
> This brings up several interesting issues.
>
> 1.  I would not try to make your domain model double as DTO's.  Not
> for the technical headaches, but for the maintenance ones.  The stuff
> a client wants in a DTO and the stuff an entity requires needs to be
> able to vary independently.  You'll either end up dumbing down your
> domain model, or fatting up your DTO's.  (And remember, if you don't
> have remote clients, you don't need DTO's!)
>

I am leaning towards this interpretation as well. We come from a Spif
(http://spif.sourceforge.net) legacy, and Spif is very much the
mindchild of the idea that we could grow a domain model from DTOs, much
to counter the tendencies a few years ago. Maybe it is time to
reconsider this policy.

>
> 2.  I'm a little squeamish about having entities depend on external
> services.  POJO policies, fine.  It seems to me that entities should
> have very fine grained relationships within an aggregate, and very
> minimal dependencies outside that aggregate.  If an entity depends on
> a remote service, that drives you towards a much coarser grained
> interface.   My instinct would be to avoid those kinds of dependencies
> within entities, and instead have the service layer pass in the
> information from the external service.  Not sure though.
>

I'll tell you the specific example. Let me know if you think it is
inappropriate. Our domain is mediating payments between different banks.
When we process a payment, we need to send it to the server of the bank
owning the debitor account to authorize the payment (reserve money). The
debit account number can determine the destination bank server. This is
a core part of our domain, but most of internals are hidden inside a
different (remote) service developed by another (in-house, but distant)
team.

So what I am contemplating is to basically let
payment.getDebitAccount().getIssuingBank().getServer() (with most of the
train wreck hidden, of course) transparently look up the "Issuing bank"
relationship through the remote interface. This is implemented as a
repository.

So in other words, part of our domain model is controlled by another
application, but we want to simulate coherent domain model to be able to
implement the business logic inside the domain model.

What do you think?


~Johannes



Yahoo! Groups Links










_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com

This e-mail message is for the sole use of the intended recipient(s) and
contains confidential and/or privileged information belonging to Siebel Systems,
Inc. or its customers or partners. Any unauthorized review, use, copying,
disclosure or distribution of this message is strictly prohibited. If you are
not an intended recipient of this message, please contact the sender by reply
e-mail and destroy all soft and hard copies of the message and any attachments.
Thank you for your cooperation.

On Mon, 18 Jul 2005, Johannes Brodwall wrote:

> On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:
> > This brings up several interesting issues.
> >
> > 1.  I would not try to make your domain model double as DTO's.  Not for
> > the technical headaches, but for the maintenance ones.  The stuff a
> > client wants in a DTO and the stuff an entity requires needs to be able
> > to vary independently.  You'll either end up dumbing down your domain
> > model, or fatting up your DTO's.  (And remember, if you don't have
> > remote clients, you don't need DTO's!)
> >
>
> I am leaning towards this interpretation as well. We come from a Spif
> (http://spif.sourceforge.net) legacy, and Spif is very much the
> mindchild of the idea that we could grow a domain model from DTOs,
> much to counter the tendencies a few years ago. Maybe it is time to
> reconsider this policy.

I completely agree with the principles of having separate DTOs, both from
a DDD, and technical viewpoint.

If your model is "perfect" you probably don't have relationships that
spawns too much of your database, but ours were not. ;) The "illusion"
that we could seamlessly use our domain objects for calls that required
serialisation lead to a lot of data beeing read from the db (lazy loading
was triggered), and some serious performance issues (serialisation of
large graphs). We cleaned up our model and now it works satisfactory, but
if I could redo it I would use separate DTOs.

Anders,

Hi,

This question raises the question about how to reference a GENERIC
SUBDOMAIN from the CORE DOMAIN. (More general, one can discuss how one
subdomain references another.) In the question, you have IProduct
referencing ProductCategory.

My proposal is to let IProductFactory have a factory method taking the
ProductCategory as an argument, but the IProduct class will store the
primary key of the ProductCategory – not a reference to the
ProductCategory object. IProduct will also have the standard
getProductCategory method. However, since it only knows the primary key,
the actual object can be found in two ways:

- The client gets the primary key and has to lookup the object in the
ProductCategoryRepository.

- The IProduct object makes the lookup in ProductCategoryRepository and
returns the ProductCategory object.

I prefer the second solution since it exposes strongly typed code to the
client. (I am a great fan of strongly typed code.)

My proposed solution introduces a dependency from the IProduct domain
(in general the CORE DOMAIN) to the repository in the ProductCategory
domain (in general the GENERIC SUBDOMAIN). I think this dependency is
the best way of doing it, since there has to be some dependency in the
code, simply because there is a dependency in the domain! I find this
dependency better than introducing a dependency between the two
repositories.

This also opens for a cache in the ProductCategoryRepository, since
product categories are more stable than products.

Besides this open reply, I have sent a more extensive note and sample
code from different projects to Nick. I don’t want to share this
information to everyone now since the note is a not-ready-yet paper,
while the sample code is a sample of parts of DDD while other parts are
quick-and-dirty implementations. Send me a mail if you want to share
this preliminary information.

/Tomas

Nicholas Robinson wrote:

> Hi,
>
> My current predicament is that I have a ProductRepository that loads
> up an IProduct. All products are categorised, so IProduct is
> associated to a category in the database. There is a
> CategoryRepository that loads objects relating to categories, which is
> typically the category hierarchy. Now, when I load a product I also
> want to find out a bunch of other data about the product, such as its
> category along with a whole load more stuff. I am therefore wondering
> if it is appropriate for my stored procedure to return a bunch of
> data, and have the ProductRepository pass the DB dataset to
> collaborating repositories - in this case it would be a
> CategoryRepository. This seems ok because it localizes the loading
> knowledge to one place for the category information. I could also
> cache the categories in the repository, and simply return a category
> id from the stored proc that gets the product data, and request it
> from the CategoryRepository as normal:
>
> _categoryRepository.Find(productCategoryID)
>
> However, there is a more general question here - how do I cope with
> this situation, ignoring the chance the cache? The reason I want to
> ignore caching for this discussion is because I know I am going to
> have to return other details such as related products, related
> subjects, items viewed by other customers. For performance reasons I
> only want to hit the wire once, so I will get a mixed dataset coming
> back which need to be converted to objects. I am having trouble
> working out how to do this well. My original thought was to have a
> property bag returned from _productRepository.Find(productID) which
> contains a bunch of named items. When a product dataset is loaded, the
> _productRepository would invoke an event, and anything else associated
> with the repository would get a chance to load their own data.
>
> This leads me to another question - these domain objects that are
> being loaded are associated logically, but not associated physically,
> and I am wondering if that is correct.
>
> Any thoughts?
>
> Nick.
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     * Visit your group "domaindrivendesign
>       <http://groups.yahoo.com/group/domaindrivendesign>" on the web.
>     * To unsubscribe from this group, send an email to:
>       domaindrivendesign-unsubscribe@yahoogroups.com
>      
<mailto:domaindrivendesign-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

This brings up several interesting issues.
1. I would not try to make your domain model double as DTO's. Not for
the technical headaches, but for the maintenance ones. The stuff a
client wants in a DTO and the stuff an entity requires needs to be able
to vary independently. You'll either end up dumbing down your domain
model, or fatting up your DTO's. (And remember, if you don't have
remote clients, you don't need DTO's!)
2. I'm a little squeamish about having entities depend on external
services. POJO policies, fine. It seems to me that entities should
have very fine grained relationships within an aggregate, and very
minimal dependencies outside that aggregate. If an entity depends on a
remote service, that drives you towards a much coarser grained
interface. My instinct would be to avoid those kinds of dependencies
within entities, and instead have the service layer pass in the
information from the external service. Not sure though.
Steve
-----Original Message-----
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Johannes
Brodwall
Sent: Monday, July 18, 2005 11:38 AM
To: domaindrivendesign@yahoogroups.com
Subject: Re: [domaindrivendesign] Entity Dependencies
We have as a goal to have as much as possible of our domain objects be
serializable, so that we can use them as DTOs as well. In Java, I think
we will have to jump through some pretty ugly hoops with custom
serialization. Does anyone have similiar experiences?
Should we:
* Drop the Serializable requirement, and develop a separate DTO model
where needed? (This will require extra code)
* Avoid the dependencies on services, repositories, etc? (This will make
our domain model more anemic)
* Do the black magic serialization thingie? (Requires lookups of
singleton-like services during deserialization)
Regarding Hibernate and DAOs: We are contemplating putting in heavier
use of Repositories from our domain objects, even though we are mostly
using Hibernate. In the cases where we have to call external services,
this may prove to substantially improve our domain model.
~Johannes
On 7/18/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:

 Our entities often have several dependencies, besides the usual dependencies on things that are part of the aggregate (child entities

and value objects).

 Most of the time, *on our project* (YMMV), they are not *external* resources, but rather POJO policy objects (calculator or formula

objects,

validator policies, etc.). If it makes things easier to test, we

might

dependency inject those policies into the entities. We're using an O/R mapper (Hibernate), so our entities don't usually have a dependency on DAO's. But sometimes they do -- for example it might be more efficient to return a filtered collection of the entity using a query (or Hibernate filter) as opposed to filtering in memory in code, and we'll encapsulate that in a DAO / repository. And we'll usually dependency inject those into the entities. (Although I think you can now map such a filtered collection in Hibernate, which would remove the need for some of these
DAO's.)
Steve
________________________________
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Jeff Lowe
Sent: Monday, July 18, 2005 10:52 AM
To: domaindrivendesign@yahoogroups.com
Subject: [domaindrivendesign] Entity Dependencies

Do you inject dependencies into Entities often? It seems like something

I try to avoid, but I may be wrong. I'm not sure if you're referring to the specific method of providing an Entity with its dependencies (i.e. dependency injection), or the concept of an Entity having external dependencies. Assuming the latter, this question suggests an issue that I keep encountering in my

own development efforts.

 I find that in order to have a domain model that is rich in behavior (as opposed to the AnemicDomainModel anti-pattern - http://www.martinfowler.com/bliki/AnemicDomainModel.html),
Entities sometimes depend on external resources (e.g. database access via a DAO, message queues, web services, etc.). Therefore I would think that having an Entity with external dependencies would be a pretty common requirement for implementing non-trivial behavior. I'm curious what other folks' experience is.
Thanks,
-Jeff
________________________________
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Rex Madden
Sent: Wednesday, July 13, 2005 2:39 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign]
Re: Repositories and Transaction Handling
Do you inject dependencies into Entities often? It seems like something I try to avoid, but I may be wrong.
On 7/13/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote: 

(We use Interceptor.newInstance to have a dependency injection framework instantiate entities.)
Steve
-----Original Message-----
From: domaindrivendesign@yahoogroups.com
[mailto:domaindrivendesign@yahoogroups.com ] On Behalf Of

Eric Evans

Sent: Wednesday, July 13, 2005 12:38 PM
To: domaindrivendesign@yahoogroups.com
Subject: Re: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re: Repositories and Transaction Handling
Dirk Riehle wrote:

We want to have exactly one EUR currency object, one USD currency object, etc. There should be only 150 or currency objects in use at any time. equals() relies on this design decision (equals is reduced to an identity check then).
If you have a free Hibernate created instance, two EUR objects won't be equal if they aren't the same object.

Dirk, doesn't that depend on how the currency object is implemented?

If
equals() compares the currency code, then two EUR objects would be equal, whether they are the same object or not. This is how a value object should behave. (Not actually sure about the Java Currency in this regard. Maybe I should check.)
Ordinarily, I would think that having a single instance of each currency would only be important as an optimization, if you had so many of them that they hogging memory or taking too much time to instantiate. Do you think this will often be the case? Or are there other reasons you want to control this?
Yahoo! Groups Links
Yahoo! Groups Links

--
Rex Madden
Director of Technology
Cyrus Innovation
IT Consulting and Agile Software Development New York City, New York
http://www.cyrusinnovation.com
rmadden@...
_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com
This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners. Any unauthorized review, use, copying, disclosure or distribution of this message is

strictly prohibited.

If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the

message and any attachments. Thank you for your cooperation.
SPONSORED LINKS
Computer backup software Computer help desk software Computer monitoring software Computer security software Computer service software Designing software
________________________________
YAHOO! GROUPS LINKS
Visit your group "domaindrivendesign" on the web.
To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ________________________________

Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/domaindrivendesign/
<*> To unsubscribe from this group, send an email to:
domaindrivendesign-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/