hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: What should be a service?
Date Thu, 02 Jun 2005 19:55:33 GMT
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:myjavaland@yahoo.com] 
Sent: Thursday, June 02, 2005 2:26 PM
To: hivemind-user@jakarta.apache.org
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 <james@carmanconsulting.com> 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:myjavaland@yahoo.com] 
> Sent: Thursday, June 02, 2005 11:56 AM
> To: hivemind-user@jakarta.apache.org
> 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 <james@carmanconsulting.com> 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:justin@stanczakgroup.com] 
> > Sent: Thursday, June 02, 2005 5:28 AM
> > To: hivemind-user@jakarta.apache.org
> > 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 <belaran@gmail.com> 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 <gstamp@gmail.com>:
> > >>
> > >>    
> > >>
> > >>> 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: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message