hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eyon Land <myjaval...@yahoo.com>
Subject RE: What should be a service?
Date Thu, 02 Jun 2005 21:32:13 GMT
Joel or Chris,

Do you have a "hello world" example that demonstrates
the kind of packaging you are proposing?  Maybe this
would be a good example to have for any HiveMind user?

My concern is what happens when you get 20 entity
classes with lots of business logic that cuts across a
variety of different entity instances?  

Do you load those entity classes with business logic?

Does "Streamlined Object Modeling" support your
suggestion?


--- Joel Trunick <joel.trunick@webifysolutions.com>
wrote:

> 
> 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:cconrad@vasoftware.com] 
> Sent: Thursday, June 02, 2005 3:08 PM
> To: hivemind-user@jakarta.apache.org
> 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: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.
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
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