docs/backend-system: add naming pattern docs

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/backend-system/architecture/07-naming-patterns.md

@@ -0,0 +1,94 @@
+---
+id: naming-patterns
+title: Backend System Naming Patterns
+sidebar_label: Naming Patterns
+# prettier-ignore
+description: Naming patterns in the backend system
+---
+
+These are the naming patterns to adhere to withing the backend system. They help us keep exports consistent across packages and make it easier to understand the usage and intent of exports.
+
+### Plugins
+
+| Description | Pattern      | Examples                            |
+| ----------- | ------------ | ----------------------------------- |
+| export      | `<id>Plugin` | `catalogPlugin`, `scaffolderPlugin` |
+| ID          | `'<id>'`     | `'catalog'`, `'scaffolder'`         |
+
+Example:
+
+```ts
+export const catalogPlugin = createBackendPlugin({
+  id: 'catalog',
+  ...
+})
+```
+
+### Modules
+
+| Description | Pattern                      | Examples                            |
+| ----------- | ---------------------------- | ----------------------------------- |
+| export      | `<pluginId>Module<ModuleId>` | `catalogModuleGithubEntityProvider` |
+| ID          | `'<moduleId>'`               | `'githubEntityProvider'`            |
+
+Example:
+
+```ts
+export const catalogModuleGithubEntityProvider = createBackendPlugin({
+  pluginId: 'catalog',
+  moduleId: 'githubEntityProvider',
+  ...
+})
+```
+
+### Extensions
+
+| Description | Pattern                          | Examples                               |
+| ----------- | -------------------------------- | -------------------------------------- |
+| Interface   | `<PluginId><Name>ExtensionPoint` | `CatalogProcessingExtensionPoint`      |
+| Reference   | `<pluginId><Name>ExtensionPoint` | `catalogProcessingExtensionPoint`      |
+| ID          | `'<pluginId>.<name>'`            | `'catalog.processing'`, `'foo.barBaz'` |
+
+Example:
+
+```ts
+export interface CatalogProcessingExtensionPoint {
+  ...
+}
+
+export const catalogProcessingExtensionPoint = createExtensionPoint<CatalogProcessingExtensionPoint>({
+  id: 'catalog.processing',
+  ...
+})
+```
+
+### Services
+
+| Description | Pattern             | Examples                                           |
+| ----------- | ------------------- | -------------------------------------------------- |
+| Interface   | `<Name>Service`     | `LoggerService`, `DatabaseService`                 |
+| Reference   | `<name>ServiceRef`  | `loggerServiceRef`, `databaseServiceRef`           |
+| ID          | `<pluginId>.<name>` | `'core.rootHttpRouter'`, `'catalog.catalogClient'` |
+| Factory     | `<name>Factory`     | `loggerFactory`, `databaseFactory`                 |
+
+Example:
+
+```ts
+export interface CatalogClientService {
+  ...
+}
+
+export const catalogClientServiceRef = createServiceRef<CatalogClientService>({
+  id: 'catalog.catalogClient',
+  ...
+})
+
+export const catalogClientFactory = createServiceFactory({
+  service: catalogClientServiceRef,
+  ...
+})
+```
+
+An exception to the above service reference naming pattern has been made for the all of the core services in the core API. The `@backstage/backend-plugin-api` makes all core service references available via a single `coreServices` collection. Likewise, the `@backstage/backend-test-utils` exports all mock service implementations via a single `mockServices` collection. This means that the table above is slightly misleading, since `loggerServiceRef` and `databaseServiceRef` are instead available as `coreServices.logger` and `coreService.database`. We recommend that plugins avoid this patterns unless they have a very large number of services that they need to export.
+
+While it is often preferred to prefix root scoped services with `Root`, it is not required. For example, `RootHttpRouterService` and `RootLifecycleService` follow this pattern, but `ConfigService` doesn't and it is a root scoped service.

microsite/sidebars.json

@@ -375,7 +375,8 @@
               "backend-system/architecture/services",
               "backend-system/architecture/plugins",
               "backend-system/architecture/extension-points",
-              "backend-system/architecture/modules"
+              "backend-system/architecture/modules",
+              "backend-system/architecture/naming-patterns"
             ]
           },
           {

packages/backend-plugin-api/src/wiring/factories.ts

@@ -74,10 +74,10 @@ export interface BackendModuleConfig {
  *
  * @remarks
  *
- * The `moduleId` should be equal to the module-specific prefix of the exported name, such
- * that the full name is `moduleId + PluginId + "Module"`. For example, a GitHub entity
+ * The `moduleId` should be equal to the module-specific suffix of the exported name, such
+ * that the full name is `pluginId + "Module" + ModuleId`. For example, a GitHub entity
  * provider module for the `catalog` plugin might have the module ID `'githubEntityProvider'`,
- * and the full exported name would be `githubEntityProviderCatalogModule`.
+ * and the full exported name would be `catalogModuleGithubEntityProvider`.
  *
  * The `pluginId` should exactly match the `id` of the plugin that the module extends.
  */