A key part of object-oriented software development is mapping design model entities to implementation model classes. Although we are used to thinking of object instances as the primary players in a runtime system, it is in fact the conceptual entities that they embody, not the instances themselves, that are truly important. Objects come and go, but what they represent lives on in the “minds” of clients. For example, a client invocation may require activating a service and instantiating a new object; or a single entity might be represented by objects in multiple processes in a system with load balancing; or a business entity can exist in a persistent data store and then be incarnated as objects in multiple services. Thus, what appears to be a single perpetual entity to clients may not currently exist as a physical runtime object, or may exist as multiple objects.

This difference between conceptual entities and the objects that serve as their vessels lies at the heart of the areas of life cycle and persistence. Questions raised by the entity/object duality that must be applied to every entity include:

• How is the entity identified so that objects know what they are implementing?

• What process or processes should the implementation objects live in?

• Does the entity exist only when an implementation object is created?

• Where and how is an entity's state stored if it exists beyond the implementation object?

• Can an implementation move?