You're right! I think your package structure makes more sense!
Thanks! Eyon --- James Carman <[EMAIL PROTECTED]> 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: > === message truncated === __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
