hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Conrad <ccon...@vasoftware.com>
Subject Re: What should be a service?
Date Thu, 02 Jun 2005 23:06:03 GMT
Hi Eyon,

For me, anything which involves manipulating multiple entities goes  
into a service.  For example, the application's authorization system  
needs to take into account a user's global role, the entity they are  
attempting to access and the user's subsystem role (their global role  
is something that marks them as a regular employee, manager, etc.   
Their subsystem role is the role they have for that particular  
subsystem like QA or Engineer.  Both need to be taken into account  
because the subsystem role can increase or decrease the capabilities  
for their global role).  The authorization service retrieves the  
necessary entities from the various repositories and calculates  
whether the user can perform the action or not.

Does that answer your question at all?

--Chris

On Jun 2, 2005, at 2:32 PM, Eyon Land wrote:

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


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