Hi Chris,

Here's my interpretation, which is, of course, open to interpretation..

* Domain object - something representing a concept in the business
domain. Something that you could ideally show to a business analyst or
client and get some vague look of recognition. 'Domain Driven Design'
by Eric Evans is a deep look at domain modeling and object taxonomy
(service, entity, value, etc)

* POJO - a plain ol' java object, but not necessarily one that models
a business domain concept. At a basic level, a Java class that doesn't
need a deployment descriptor or some other separate metadata to fully
define its functionality. POJOs are considered good building blocks
for business logic, since the logic isn't dependent on a particular
deployment technology or development framework (portability)

* Data Object - something that holds data but does not provide
behaviour. So an Address (street, postcode, state, etc) could be a
data object with get() and set() methods but nothing else. A data
object may also be a domain object if it represents a concept from the
business domain. Then again, it could just represent a URL for a web
service endpoint, or a JDBC driver configuration.

For domain objects that are not persisted - I'm not aware of any
standard term. I've heard these kinds of things called "value objects"
(see Eric Evans), "derived objects", "calculated objects" and "object
views" ('view' is a heavily overloaded term, however)

Where your business + calculated objects live is entirely a function
of your architecture, not a result of correctly or incorrectly use.
Think of a web-based system - your business and calculated objects
almost certainly will live in the server, not inside the web browser;
but a rich GUI client may use a different approach.

Cheers
Mike