Tips for Naming Components 

When naming components, adhere to the following simple rules:

·        The names of software components (SCs) and components (DCs) must be globally unique and static. The name of a component must be defined upon creation of that component and must not be changed afterwards. For more information on reserving globally unique component names, see Component Names.

·        Dependencies between SCs are not declared for actual states or versions. Therefore, the names of software components should not contain explicit version or release identifiers.

Avoid names like example.org/component_1.0 and example.org/technology_6.30.

Instead, use simple names like example.org/component and example.org/technology.

·        The assignment of DCs to SCs is not static and may change over time. Therefore, the name of a DC must not contain the name of the SC to which it will be assigned nor a version or release identifier of the SC.

Avoid names like example.org/sc/1.0/accounting. Instead, simply use example.org/accounting. Only if it serves to avoid ambiguity (for example, if another SC contains a component of the same name), can it be reasonable to use the SC name as a prefix, for example, example.org/sc/accounting.

·        Dependencies between DCs are not declared for actual states or versions. Therefore, the names of components should not contain explicit version or release identifiers.

Avoid names like example.org/accounting/release_6.30. Instead, simply use example.org/accounting.

·        The parent/child relationship between DCs is not static and may change over time. The name of a child DC can reflect the enclosure relationship, but this is not recommended, because such a name may lead to confusion when the relationship is changed. If it is probable or known that the structure of a component hierarchy will change (for example, a child component will be taken out of its parent’s enclosure), the name must not refer to the relationship.

The name example.org/customer_releations/accounting can become a problem, if example.org/customer_releations/accounting is now a child component of example.org/customer_relations, but is meant to be assigned to the new component example.org/financials later.

·        Certain states of a DC may simultaneously be referenced from different workspaces (for example, from DEV and CONS). Therefore, the workspace identifier must not be part of the DC’s name.

Avoid names like example.org/accounting/DEV and example.org/accounting/CONS.

·        Component names should not contain versioning or state information of any kind . This includes, for example, things like “specification” and “implementation” versions used on the J2EE platform.

·        Component names must have a globally unique vendor identifier. This identifier is usually derived from an Internet domain that belongs to the vendor (for example, "sap.com").

If the Internet domain with the identifier example.org belongs to you, use it as a prefix to your component names, for example, example.org/accounting. This makes your component names unique among all vendors.

·        Component names should not contain identifiers of developers, groups, or departments of a company. Responsibilities may change, but component names must not. Furthermore, do not use timestamps, dates, hosts, and so on..

Avoid names like example.org/department4711/accounting, example.org/john.dow/accounting or example.orgaccounting/09_11_2003_09.27pm.

·        Component names should reflect the intended purpose and functionality of a component, and nothing else.