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. > >>> > >>> Regards, > >>> > >>> Glen Stampoultzis > >>> > >>> > >>> > >>> > >> > >> > > > >--------------------------------------------------------------------- > >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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
