Domain object are classified as aggregates, entities and value objects. Here we classify them along another dimension as transactional, reference or configuration objects. This classification is bounded context specific, as their role changes with the context.
Transactional objects form the core domain in a context. The services in this context care most about them. The queries are interested in their state and command manipulate and create these objects. In this context reference and configuration objects remain unchanged and they play a supporting role.
Reference objects are referred to by transactional objects to provide additional information. This information doesn't determine the business logic in any way, in the current bounded context.
Configuration objects are like reference objects except they do determine the outcome of business logic. Quite often these objects are not stored in the database but thats not a necessity. In either case these should treated as part of domain model. An application two types of configuration, deployment and functional. Configuration objects are really functional part of the configuration. Things like which location of remote services the application interacts with, database URL, log file configuration belong to the other category called deployment configuration, as they do not have any bearing on the outcome of requests and commands.
Transaction objects refer to reference objects while later are agnostic of former. We would see that this classification of domain objects is useful in modularizing large applications.