Service POJO's and Business Objects

[Gregg Bolinger]

Quick question...

I use services in some of my projects. These services do things like utalize DAO's to talk to the DB, send Emails, etc. They are basically POJO's with an interface and an implementation of each interface. This all seems like Business Object work to me, but I've never been clear on if there is really a seperation. Are they basically the same thing? Keeping in mind this has nothing to do with EJBs.

Thanks.

[Peer Reynders]

Who's yardstick do you want to apply?
According to Eric Evans the services you describe are clearly infrastructure services. As such they may appear in your domain model, but they do not classify as domain services due to the lack of domain logic.

[Frank Carver]

The rule of thumb I use is that the code in a good business object should read a lot like a textual description of the process. It describes the "what" rather than the "how", while the "how" is delegated to more generic infrastructure services. Code in business objects should be easily explained to, and verified by, business people with little software infrastructure knowledge.

Or, looked at another way: If your service only makes sense in the context of this application, and would almost certainly have to be rewritten if/when the business requirements of the application change, it's probably a business object. If your service is flexible enough to provide for more than just the current business requirement, it's probably an infrastructure service. If it's a mixture of both, then there's a good chance it would benefit from being split to make the distinction clearer.

Does any of that help?

[Gregg Bolinger]

Thanks Frank. That helps clear some things up.

[Stan James]

The rule of thumb I use is that the code in a good business object should read a lot like a textual description of the process.

I like to say "The code should sing to me of insurance!" or whatever your domain is. If it's half insurance and half twiddling bits and half housekeeping for the framework we're missing some abstractions. And some math skills.