Naming Conventions

When building NS applicationNS Application (NSApplication). A pre-built software stack that provides common enterprise application functionality such as CRUD, search, authentication, and business process modeling out of the box. models, it is important to stay consistent and follow naming standards as closely as possible. The content of the models is used to generate all sorts of artifactsArtifactA build or deployment result, such as a Docker container image or Java archive, produced by a software project., which means that a dependable naming scheme is an excellent help to produce clean and consistent results.

As a general rule, we try to use the English language in all models. As English is a language that is used very commonly in many industries, this makes the models considerably more accessible. It also reduces the need of finding translations for technical terms that often originated in English.

caution

Avoid using names such as common terms that are frequently used as "reserved words" in programming languages, such as (but not limited to) case, export, function, id, import, interface, name, long, package, parameter, string, var.

Element naming rules

• ApplicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution./ApplicationInstance element:
  • A relevant name for the applicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. in camelCase.
• Component element:
  • A unique name in camelCase to facilitate the exchange of components.
  • The name of a component should describe the specific concern it encapsulates, rather than being generic.
• DataElement element:
  • The name of a DataElement should always be a singular noun in PascalCase, that is unique within its component.
  • Ideally the name of a DataElement is anthropomorphic (describing a real life concept).
  • Avoid using words such as Data, Info or Details in the name of a DataElement, as these are used as suffixes for many classes generated in the JEE ApplicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. Stack.
• FieldFieldA property of a DataElement expanded to a database column and user interface input element. element:
  • The name of a FieldFieldA property of a DataElement expanded to a database column and user interface input element. should always be a singular noun in camelCase, that is unique within its component.
  • Avoid reusing the name of the DataElement in one of its fieldsFieldA property of a DataElement expanded to a database column and user interface input element..
    Anti-Pattern Example

    Dog.dogName would be a bad fieldFieldA property of a DataElement expanded to a database column and user interface input element. name, as the dog in dogName is redundant if the name of the DataElement is already Dog. The context of the FieldFieldA property of a DataElement expanded to a database column and user interface input element. as part of the DataElement implies that the name is the name of a Dog.

• FinderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. element:
  • The name of a finderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. should always start with findBy, except for findAll and custom findersFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement..
  • FinderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. operator pairs (fieldFieldA property of a DataElement expanded to a database column and user interface input element. name + operation) in the name of a finderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. should always be written in PascalCase. When multiple finderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. operator pairs are used, they should be separated with an underscore in the name.
    Example

    • A finderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. used to search by the fieldFieldA property of a DataElement expanded to a database column and user interface input element. name with operator Eq: findByNameEq
    • A finderFinderA search specification combining field-operator pairs to execute standard data queries on a DataElement. used to search by the fieldFieldA property of a DataElement expanded to a database column and user interface input element. code with operator Se and invoicedAmount with operator Gt: findByCodeSe_InvoicedAmountGt
• TaskElement element:
  • The name of a TaskElement should be a singular noun in PascalCase.
  • The name should be a noun derived from a verb. It should describe the action being performed by the task.
    Example

    • A task which sends an email could be named SendEmail. The name is derived from the verb "to send".
    • A task which reports errors to a server could be named ErrorReporter. The name is derived from the verb "to report".
• Workflow element:
  • The name of a FlowElement should be a singular noun in PascalCase.
  • A common practice is to use the suffix "Flow" in the name for clarity, though it is redundant given that it is an instance of FlowElement.
• DataCommand element:
  • The name of a DataCommand should be a singular noun in PascalCase.
  • It is bad practice to suffix the name with "Command".
    Anti-Pattern Example

    A command to set the enabled state of an element should not be called SetEnabledStateCommand. In the JEE ApplicationApplicationThe overarching model container grouping all components, domain logic, and configurations for an enterprise solution. stack, every DataCommand of a DataElement is implemented as a nested class of <DataElement>Command. As such, the resulting class would be <DataElement>Command.SetEnabledStateCommand, which clearly shows that Command in the name of the DataCommand isredundant.

• States element:
  • The name of a state depends on the type of state:
    • A begin- or endstate should be a singular noun that indicates the current state of the DataElement it applies to.
      Example

      A newly created instance of a DataElement could have the beginstate Initial, whereas after being processed by a task, it could be assigned the endstate Registered.

    • An intermittent state of a DataElement should be a name derived from a verb that describes the action being performed.
      Example

      A DataElement that is being processed, going from states Initial to Registered, could have an intermittent state Registering.

    • A failed state of a DataElement that occurs when a task failed to perform an operation, should be named after the action and have the suffix "Failed".
      Example

      A DataElement that is being processed, going from states Initial to Registered, could be set to the failed state RegisterationFailed if a task fails.

• DataOperation element:
  • The name of a DataOperation, and of its parameters and parameter groups, should always be written in camelCase.
  • The working name of a DataOperation is its name suffixed with the name of its DataElement.
  • The root group always inherits the name of its DataOperation. Every additional group requires a name, which is added as a suffix to the working name.
    Example

    • An operation named register on DataElement City has the working name registerCity.
    • A group named address on that operation has the working name registerCityAddress.
• DataOperation type:
  • Operation types use a dot-separated PascalCase convention, such as Create or BatchUpdate.
  • Custom types should be prefixed to add scope. Project-specific types should use the project name as the prefix.
    Example

    • Workflow.Trigger is a type defined for triggers within the workflow context.