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.
I attempted to model my example application which
accompanied my article
(http://www.theserverside.com/articles/article.tss?l=HivemindBuzz)
on
TheServerSide.com using some of the ideas presented
in Mr. Evans book. In
my mind, he does prescribe some useful patterns.
Of course, if you're asking what should be a
"HiveMind Service", then both a
domain "service" and a "repository" would count as
HiveMind services (as
would factories). In a domain model, though, a
repository and a service are
completely different beasts.
p.s. The official title of the article was supposed
to be "HiveMind: What's
All the Buzz?" For some reason, the editor at TSS
decided to change it on
me. So, please forgive the current title. I think
the original one was
much more catchy!
-----Original Message-----
From: Eyon Land [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 11:56 AM
To: [email protected]
Subject: RE: What should be a service?
I come from the Spring world. My team and I
recently
deployed an application (with Spring) and we saw
Services as components with business logic that
crossed domain objects. A set of domain classes
are
the "nouns" in your system. These are NOT services
in
our opinion. And you may have some business logic
in
your domain classes. Thats OK so long as the
business
logic does not cross over into many domain classes.
As mentioned below, the User class is a domain class
and it is OK to put business logic in the User class
so long as it pertains only to a single instance of
the User class. But lets say you have requirements
that include some sort of business logic between
domain classes (even between multiple instances of
the
same domain class), then you need to create a
service
for this. That way it can be easily reused no
matter
what the presentation layer is. And even more
importantly, the services can easily be changed if
your requirements change! Presentation logic should
not be in the services. However I think it is OK to
create a Controller as a service because often a
controller has some sort of logic directing flow
between your services.
As someone else mentioned, a DAO is a service
because
it is providing logic between a domain class and the
database.
Not sure that I'm doing a great job at explaining
this
but perhaps a word from the creator of HiveMind
might
be worth a listen!
Eyon
--- James Carman <[EMAIL PROTECTED]> wrote:
You have to be careful not to create an "anemic
domain model"
(http://www.martinfowler.com/bliki/AnemicDomainModel.html)
when you approach
your architecture this way (I'm guilty of this).
Some stuff should actually
go in the User class itself as opposed to being in
a
service.
-----Original Message-----
From: Stanczak Group
[mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 5:28 AM
To: [email protected]
Subject: Re: What should be a service?
I'm very new to this as well, but shouldn't a
service be anything that
has action on your data? What I mean is say you
have
a user object.
That's your data. Then anything that acts upon
that
data should be a
service. So login, email, password recovery etc...
should all be actions
that act on that data the user object. Then the
part
that you build is
the logic that routes the users actions to the
proper services. In my
mind that's where I draw the line. Each service
can
use another services
resources, but I wouldn't have one service that
controls all the logical
flow of my program. So I guess to summarize,
HiveMind is used to
encapsulate actions (aka, services) into
manageable
modules. Again I'm
sure I'm not completely correct because I'm also
new
to HiveMind as well.
Glen Stampoultzis wrote:
Sounds sensible however a service being a
component
doesn't really tie
it down for me much. I guess there is no clear
boundary.
On 6/2/05, belaran <[EMAIL PROTECTED]> wrote:
The way i see it a "service" should be
component...
For instance,
For a simple web app using hivemind, you could
a
DAO service to access
the database , a bizness service that's actually
those the work and maybe a
third service, that'll realize the XML/XSL
transformation.
That's my point of view, but i'm still a
beginner, so maybe i'm wrong....
Belaran
2005/6/2, Glen Stampoultzis <[EMAIL PROTECTED]>:
Was just wanting to get some peoples opinions
on
what sort of things
should be made into hivemind services?
It seems to me that it would be pretty easy to
go crazy and make all
sorts of services but I'm thinking that would
probably be a bad idea. Where
do you stop? I'd be interested in hearing real
life
services people have
created.
=== message truncated ===
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend.
Check it out!
http://discover.yahoo.com/weekend.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
