hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Trunick" <joel.trun...@webifysolutions.com>
Subject RE: What should be a service?
Date Thu, 02 Jun 2005 21:11:36 GMT

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


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