I agree, this is the way I do it. Chris Conrad wrote:
> 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] > > -- Justin Stanczak Stanczak Group 812-735-3600 "All that is necessary for the triumph of evil is that good men do nothing." Edmund Burke ..________...............__................. ./ _____/..____..._____/..|_..____...____.... /...\..____/.__.\./....\...__\/.._.\./._..\.... \....\_\..\..___/|...|..\..|.(..<_>.|.<_>..).... .\______../\___.._\__|../__|..\____/.\____/...... ........\/.....\/.....\/.......................... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
