The best definition of "domain object" I've found in literature is in Chapter 11 of TimHoward's book TheSmalltalkDevelopersGuideToVisualWorks pp.379-381:

"a domain object is a logical container of purely domain information, usually represents a logical entity in the problem domain space ...
In general, domain objects should know how to
	* recognize which [of their] references indicate aggregation and which ones indicate association
	* copy themselves
	* maintain business logic
	* compare themselves to other domain objects of the same type
	* facilitate other objects that choose to print or display them
	* conduct tests on their domain information"

To this list I would add
	* identify themselves
	* validate themselves

--RandyStafford

I would also add
	*domain objects direct their persistence
	*there may be collections of Domain objects
	*domain object may contain references to other domain objects (this is assumed by the first one above).

--Fritz Schenk

I am not in agreement with Fritz Schenk on one point. Domain objects should not direct their persistance. They don't know how to be persisted and even if they will be persisted. The infrastructure layer is there for that.

-- Alexandre de Pellegrin

I disagree with Fritz on both of the other points, collections and references.  The original list of attributes made both of his points better than he.  (Collections via aggregation and association)

-- K Ford

----
See also: BusinessObject, DomainModel
----
CategoryJargon