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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Thursday, June 02, 2005 3:08 PM > To: [email protected] > 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:[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. > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
