Defining a Domain Hierarchy

Another advantage of using domains is that it allows changes to the datatypes of related attributes to be effected simply by changing a domain definition. Say, for example, that a particular type of reference number changes from a 10-digit to a 12-digit number. The reference number probably appears as an attribute in many different entities and structures. As long as these attributes have been defined in terms of a common domain definition, they can all be changed together by modifying the domain definition (obviously, there will also be database impact, etc. to consider).

By defining domains in terms of other domains, it is possible to set up a hierarchy of related domain definitions. For instance, consider the following entity classes and their domain-specified attributes:

• entity class: Customer

  Attribute	Domain
  details address_1	CUSTOMER_ADDRESS_LINE
  details address_2	CUSTOMER_ADDRESS_LINE
  details address_3	CUSTOMER_ADDRESS_LINE

• entity class: Employer

  Attribute	Domain
  details address_1	EMPLOYER_ADDRESS_LINE
  details address_2	EMPLOYER_ADDRESS_LINE
  details address_3	EMPLOYER_ADDRESS_LINE

In the above tables, the address attributes of the Customer and Employer entities are defined in terms of CUSTOMER_ADDRESS_LINE and EMPLOYER_ADDRESS_LINE respectively. Both of these domains are in turn defined in terms of the ADDRESS_LINE domain. All of the domains ultimately unwind to a 30-character string primitive datatype.

The following rules of thumb should be followed when defining attributes:

• attributes whose types must be able to vary independently of each other should be defined in terms of different domains;
• attributes that should always have the same types should be defined in terms of the same domain;
• attributes that initially have the same type, but might in the future vary independently should be defined in terms of related domains.

Thus, in the example, it is possible to change the ADDRESS_LINE domain in order to change the types of all entity address line attributes, but the Customer and Employer address line attributes can also be varied independently. Given different design decisions, the entity address line attributes might just have been defined in terms of ADDRESS_LINE (on the assumption that all address lines will always have the same type), or each address line might have had a separate domain definition (on the assumption that address lines 1, 2, and 3 might not always be the same size).