The `ovm.core.domain` package contains the interfaces that deal with domain-specific information, along with actual VM object type information and layout.

A domain is essentially an application space; applications running in different domains have (conceptually) no interaction via shared objects. Two different domains might well contain two classes with the same name but different implementations (for example, one domain may contain a class that uses one version of `java.lang.String`, whereas another application may expect a different implementation of this class). The domain with which the application is associated will determine where classes will be searched for at resolution time.

Information about objects and their types is stored in two different data structures. A `Type` contains information about a class and its structure and domain. Some information within a `Type` may be resolved lazily. A `Type` has a reference to its `Context`, which contains a reference to the `Type's` domain. Thus, every `Type` belongs to exactly one `Context`, and every `Context` refers to exactly one `Domain`. The `Type` can then be seen as a domain-specific representation of class information.

Each `Type` is corresponds to a `RepositoryClass`; the `RepositoryClass` encapsulates the repository's view of the information contained in a class file. The `Type` object represents a particular domain's view of the associated class. (This means that there could be several different `Type` objects associated with a given `RepositoryClass` object.)

As mentioned in the before, some information within a type may be filled in lazily. For example, if a class has a field which is never assigned to, the class representing that field's type may never be loaded. Since the field's type may never be resolved, the `Type` doesn't bother to encode that information until the actual resolution occurs. `Type` objects, then, may evolve at runtime.

A `Blueprint`, on the other hand, represents an object's layout and the information necessary to create an instance of that object. This may include virtual method tables and other information, but this depends upon the implementation of `Blueprint`. Once an object has been created with a given instance of `Blueprint`, that `Blueprint` is then considered immutable.

There is not necessarily a one-to-one mapping between `Types` and `Blueprints`. Every `Blueprint` does have exactly one associated `Type`; however, it is possible that an implementation may choose allow a `Type` to have several different `Blueprints` for various reasons. For example, if there were a reason to add some bookkeeping information to some instances with a given `Type`, but not all of them, a second `Blueprint` could be associated with the type that had additional space for this information. Multiple `Blueprints` corresponding to the same type must still be compatible, however.

`Domains`, then, are containers for `Blueprints` and `Types`. Similarly, a `Type` may have multiple `Blueprints`.

Every object in the language being implemented is visible to the implementing language as an `Oop`. Each `Oop`, as the representation of an object, has a `Blueprint`; this `Blueprint` has a reference to its `Type`.

Other associated objects, such as class member objects, are also included in the `ovm.core.domain` package. See specific class descriptions for details.

N.B.: For the time being, there is a one-to-one correspondence between `Type` objects and `Blueprint` objects. However, KP indicated that this will hopefully change, at least as far as the higher-level concept is concerned (i.e. implementations may choose to keep this one-to-one, but this is a special case of one-to-many).

An example of the interaction between `RepositoryClass` objects, `Types`, and `Blueprints` is shown below. This figure is based upon the following code:

          class A {
              static int bar;
              public int foo;
          }

As the figure shows, each instance of `A` is associated with a `Blueprint`. The instance object itself contains the values associated with that instance (in this case, the value of `foo`). Here there are two instances of `A` shown: `a1` and `a2`. Both were created from the same `Blueprint`, but could have different values for `foo`.

The `Blueprint` associated with `a1` and `a2` describes the instance object layout. In this case, for example, it contains information about the offset of `foo` within the object. It also contains a reference to the `Type` object associated with class `A` in this domain. It also contains a reference to a shared-state object for class `A` as well as a reference to the `Blueprint` for all objects of class `Blueprint`; these are discussed in more detail below.

A shared-state object is associated with each `Type` object. It functions much like an instance object, except that it contains any shared-state information for the class and, as such, there is only one such object per `Type`. For example, in `Java`, this object contains the values of `static` variables. In our example, then, this object would contain the value of `bar` for all instances of class `A`, since it is a class variable, not an instance variable.

Like instance objects, the shared-state object has a `Blueprint` which describes its layout, including the offsets of member variables. To ensure that there is not an infinitely recursive chain of shared-state objects, the shared-state pointed to by a shared-state `Blueprint` is `null`. The `Type` object referenced by a shared-state `Blueprint` is the same `Type` referenced by instance objects of the class. As with instance object `Blueprints` (and indeed all `Blueprints`), there is a reference to the `Blueprint` for instances of class `Blueprint`.

For reference, it should be noted that `Blueprint` extends `Oop`. As mentioned before, all `Oop` objects have a `Blueprint`. Thus, instances of class `Blueprint` also have a `Blueprint` describing their layout. In the figure, all `Blueprint` objects contain a `Blueprint` reference. As shown, these all point to the `Blueprint` for instances of the `Blueprint` class. This `Blueprint` contains the same kind of information that the `Blueprint` for instances of class `A` contains; a reference to the `Type` object associated with class `Blueprint`, a reference to the shared-state object, etc.