The style Chris suggests is I believe more scalable
in some regard, and
probably correspond nicely with the HiveMind way of
thinking, build
issues aside (are you using Ivy?). It's logical as
far as becoming a
"software factory".
I'm curious about James' post though, are you
putting the logic in your
Factories, or just delegating them to say static
methods on your
entities? Wouldn't that be the logical place for
them? I have a general
problem with service layers in that they tend to be
difficult for the
user (of the service layer) to comprehend where to
go to get something
done. It's much more intuitive to operate directly
on objects you fetch
rather than on "indirect operations" that services
present. On the other
hand, repositories seem straightforward enough. As
an aside, I
emphatically agree with the Domain-Driven book that
Criteria API's fit
really nicely for implementing repositories
(Hibernate -1, Cayenne +1).
"Streamlined Object Modeling" is a good book about
laying out where to
place logic as well, but it's not clear to me when
you talk about
sending emails etc. I can see putting that in a
service layer, but I
think exposing "events" (ie. "New User event") from
the domain layer
could solve that as well.
Joel
-----Original Message-----
From: Chris Conrad [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 3:08 PM
To: [email protected]
Subject: Re: What should be a service?
Just to throw my two cents in here, I've never liked
this style of
packaging, it doesn't tell me anything about the
structure of the
application. I've always done my packaging based on
distinct feature
sets or modules in the application. For example,
I'd have
com.myco.account package which contains all the
entities, services
and repositories which are "publicly" exposed and
relate to account
management. Then I might have a
com.myco.account.impl package which
contains implementation specific stuff that
shouldn't be used by
anyone outside of the account module. This makes
the boundaries
between different sets of functionality in your
application clear.
On the flip side, it does tend to create packages
which my have only
1 or 2 classes in them.
--Chris
On Jun 2, 2005, at 12:55 PM, James Carman wrote:
I think we're running into a terminology issue
here. When you say
"domain"
class, do you mean things like User, Account,
PurchaseOrder, etc.?
I agree
that those are domain classes, but they are a
special type of
domain class.
They are "entities." Entities are the "nouns" of
your system. I
usually
don't let them reference the repository, either.
Anyway, services and
repositories are also domain classes. They are
all part of your
"domain
model." They are all used to represent/model the
"problem domain" or
"business domain." So, using that terminology, I
usually structure my
packages like:
com.myco.domain.entity
com.myco.domain.service
com.myco.domain.repository
com.myco.domain.factory
How does that sound to you?
-----Original Message-----
From: Eyon Land [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 2:26 PM
To: [email protected]
Subject: RE: What should be a service?
Most stuff I've read agrees with what you stated
about
DAOs.
A lot of people do packages such as
org.mycode.domain (has all domain classes)
org.mycode.domain.doa (has all dao interfaces)
org.mycode.domain.doa.impl (has all dao
implementations)
org.mycode.service (has all services with business
logic)
If your design is such that domain classes
actually
reference the DAOs then I can see why....
But I find in practice it's easier to maintain the
code if it is organized like...
org.mycode.domain (has all domain classes)
org.mycode.service (has all service interfaces)
org.mycode.service.impl (has all business logic)
org.mycode.service.doa (has all dao interfaces)
org.mycode.service.doa.impl (has all dao
implementations)
The reason for this is because services with
business
logic have a dependency on the DAOs with
repository
logic.
I avoid creating dependencies from domain classes
to
DAOs.
If in practice we see a dependency between a
service
(with business logic) to a DAO with (repository
logic)
why not put the DAOs under the service package?
I would be very interested in everyone's
opinion/arguments!
Eyon
--- James Carman <[EMAIL PROTECTED]>
wrote:
I have been reading the book Domain-Driven Design
(http://domaindrivendesign.org/book) lately. In
his
book, Mr. Evans refers
to what we typically consider a "DAO" as a
"repository." A service would be
something completely different (much like what
was
described in the message
below). A repository, however, can be thought of
as
a collection of
"entity" objects (a User would be an entity) of a
particular type. So, a
UserRepository would contain User objects. It
would
have methods on it
like...
User getUser( String username );
To an outsider, a repository should look/feel
like
just an in-memory
collection of objects. Now, in reality (at least
my
reality), they would
most likely be backed by a database of some sort.
But, when designing your
domain model, you should think of them merely as
a
collection of objects.
They key point, though, is that the repository
(or
DAO) IS a part of your
domain model, as domain classes need to be able
to
locate objects by certain
criteria.
