Naming conventions

Plugin name

• Must be unique across the platform ecosystem
• The plugin name in the plugin's Policy.json must be the exact same as the Kotlin or Swift plugin class name. In iOS, the plugin name in PatformHubPluginsConfig.json must also match this exact name
• Must not be empty
• Must be PascalCased. Example: SomeNamePlugin
• No symbols are allowed
• Must always end in "Plugin". Example: SomeNamePlugin
• Must contain a word expressing its architectural intent:
  • Journey
  • DomainModel
  • Capability plugins don't need any specific word

Examples:

• AccountsJourneyPlugin
• AccountsDomainModelPlugin
• NetworkPlugin
• BalanceAfterBillsJourneyAdapterPlugin

Adapter plugin name

• Must always end in "AdapterPlugin". Example: SomeNameAdapterPlugin

Message name

• Must be unique within the plugin it belongs to
• Must not be empty
• Name format:
  • In Android it must be PascalCased. Example: SomeMessageName
  • In iOS it must be camelCased (so they can be directly mapped into enums e.g. fetchAccounts.). Example: someMessageName
• No symbols are allowed

Event Stream name

Their events notify of a change that has already happened, therefore they name must be in past participle.

Example: For an event stream that publishes an event every time the accounts balance has been updated, instead of calling it balanceUpdate, name it balanceUpdated.

Command name

As their name suggests, they are orders that one plugin gives to another, therefore they must be in imperative. For clarity, please avoid using the verb "get" since it is already used to identify queries (see bellow).

Example: updateAccountBalance

Query name

They are messages that expect an immediate answer, therefore they must express the data they are expecting to receive. Starting their name with the word get is a good indicative of their intend.

Example: getTime

View Query name

They follow the same concept as the Queries with the particularity that the data we are expecting to receive is always a view. Having this in consideration their names must start with get, followed by the name of the specific view we are going to retrieve and finish with view.

Example: getAccountsListView

As a first thought it may look like a good idea use names as launchAccountsJourney, openHelp, startCreditCardApplication, etc. But a journey can have (or potentially have in the future) multiple entry points for different use cases, and they may be presented or used in different ways by their callers. The only thing we can assume with certainty is that the caller will get a particular view, hence getAccountsListView is the most accurate and future proof name we can give the view query.

Topic name

• Must be unique across the platform ecosystem
• The topic name in the plugin's Policy.json must be the exact same as the Kotlin or Swift plugin class name. In iOS, the plugin name in PatformHubPluginsConfig.json must also match this exact name
• Must not be empty
• Must be PascalCased. Example: SomeTopicName
• No symbols are allowed

Topic message name

• Must be unique within the topic it belongs to
• Must not be empty
• Name format:
  • In Android it must be PascalCased. Example: SomeMessageName
  • In iOS it must be camelCased (so they can be directly mapped into enums e.g. fetchAccounts.). Example: someMessageName
• No symbols are allowed

Plugin framework/module name

• Android: Follow the same naming as for the plugin name. The Artifact ID for Android must contain plugin.

• iOS: Must have the same name as the plugin but to avoid collisions between the plugin class name and the framework/module name, it must end in Kit.

Examples:

• AccountsJourneyPluginKit
• AccountsDomainModelPluginKit
• NetworkPluginKit
• BalanceAfterBillsJourneyAdapterPluginKit