domain object vs. business object

The terms "business object" and "domain object" are
mutually exchangeable in common understanding in
enterprise computing. Note that wikipedia links
to the same article for both terms:

In re-motion, these terms are related, but not
mutually exchangeable. Important
differences exist, and this page clarifies these differences
and the precise meaning of each term.

Both business objects and domain objects are
collections of properties, modelled after the real-world
entities you want to manage with your application. For example,
if you want to manage people with your re-motion application, you
might want person objects. A toy person object
can consist of these (typed) properties:

First name = "Sigmund"
Surname = "Freud"
Title = "Doctor"
Birth date = "1856-05-06"

To this vague explanation all enterprise programmers can
agree. What about the differences?

In re-motion,

a domain object can persist its value in a database
a business object exposes an IBusinessObject interface,
so that a binding layer can discover which properties constitute
the (business object)

If we understand the Dr. Freud object listed above as a
business object, we know that we can use the IBusinessObject
interface to initiate a dialog like this:

Q: Unknown object, what' your class?
A: Person
Q: What properties constitute that class?
A: A first name, a surname, a title and a birth date.
Q: What are the values and types of those?
A: the first name is the string "Sigmund";
the surname is the string "Freud"; the title is the string "Doctor";
the birth-date is the date "1856-05-06".

After such a conversation, re-bind (or some other binding layer, that's the
beauty of it) knows everything it needs to display all of Dr. Freud's values
in a form or a list. That's the business object aspect of that instance,
and it is most important for re-bind.

If we understand the Dr. Freud object as a domain object, we can
be sure that it can load and store itself from and to some database.
That's the domain object aspect of that instance, and it is most
important for re-store.

Not all business objects are domain objects

Aren't all domain objects business objects? What's the point of a business
object that can't be persisted?

Note that re-store and re-bind are completely independent from each other.

re-bind might bind to non-re-store objects (such implementations exist at rubicon)
re-store might be used in a command line tool that has no need for re-bind, because
nothing is displayed (such programs do exist mainly for data migration or diagnostics)

"Search objects" expose an IBusinessObject interface, but are never persisted.
Like domain objects, they are sets of typed properties, but these properties are
search terms, not components of objects you want to manage. If you have person
objects in your application, it is a good idea to have person search objects as
well:

First Name = whatever
Surname = "Smith"
Title = Ph.D.
birth-date = before 1970-01-01

This search object represents a query that gives you all Ph.D.s named Smith who
are born before 1970. It exposes an IBusinessObject interface,

because it is made of typed properties
IBusinessObject is useful for discovering typed properties

Conversely, domain objects DON'T expose an IBusinessObject interface.
If you want objects with persistence AND an IBusinessObject interface, you
must resort to bindable domain objects. BindableDomainObject is the base
class for all re-motion web applications, because they are domain objects (persistence)
AND business objects (can be displayed by re-bind).

domain object vs. business object

Not all business objects are domain objects

See also