Naming Conventions
This document defines the formal naming conventions for all system artifacts in Arda’s platform.
Identifier Forms
Section titled “Identifier Forms”Three standard identifier forms are used throughout the system:
- lower-kebab-case: a sequence of words in lower case joined with a dash
-(e.g.,item-data-authority) - lowerCamelCase: a sequence of capitalized words joined without a separator, with the first word’s first letter in lower case (e.g.,
itemDataAuthority) - lower_snake_case: a sequence of names in lower case joined with an underscore
_(e.g.,item_data_authority)
Primary Naming Conventions
Section titled “Primary Naming Conventions”These conventions are actively created by engineers during design and implementation.
Canonical Identifier
Section titled “Canonical Identifier”Given a Component C and its constituting Modules M1, M2, M3, …:
- The canonical form is lower-kebab-case
- The canonical name does not have generic trailing suffixes like
-component,-module, or-data-authority - The name aims to be short — one or two nouns
Examples:
qr-lookup— correctqrLookup— incorrect (not lower-kebab-case)item-data-authority— incorrect (has generic trailing suffix)
Repository
Section titled “Repository”Each Component has exactly one repository with the canonical component name:
- The repository contains all source code of the Component (documentation may be separate)
- The repository does not contain other Components
- In a Kotlin Component, the repository contains one Gradle project with the canonical component name
Kotlin Packages
Section titled “Kotlin Packages”All Kotlin classes are grouped into packages by the Module they belong to. All Module packages are “under” a package for the Component.
Package naming rules:
- Starts with
cards.arda - Immediately followed by the lowerCamelCase Component name
- Optionally followed by the lowerCamelCase Module name
Examples:
cards.arda.pdfRender.shopAccess.PdfRenderModule— correct (class in ModuleshopAccesswithin ComponentpdfRender)cards.arda.accounts.system.tenant.TenantModule— correct (Moduletenantunder Componentaccounts)cards.arda.pdfRender.PdfRenderModule— incorrect (class is in Component, not in a Module)cards.arda.pdfRender.shopaccess.PdfRenderModule— incorrect (Module name not lowerCamelCase)
API: Ingress
Section titled “API: Ingress”The Ingress is exposed by the Service only to other Services in the Kubernetes cluster.
The ingress path is the combination of:
- The Module API version
- A
/ - The lower-kebab-case form of the Module name
API: Route
Section titled “API: Route”The Route is exposed by the API Gateway to other systems. It is the published API of the Component and must only evolve intentionally.
It is recommended, but not mandatory, for the Route to equal the Ingress path. During transitions, multiple Routes may map to the same Ingress.
See also API Design: URL Naming for the full hostname and path convention.
Database
Section titled “Database”The database name is the lower_snake_case form of the Module name.
Secondary Naming Conventions
Section titled “Secondary Naming Conventions”These names are derived from primary names by combining Component and Module names according to ecosystem conventions.
Docker
Section titled “Docker”The Docker image name is: <component-name>/<module-name>
- The main Chart name is the Component name
- The release name is the Component name
Kubernetes
Section titled “Kubernetes”Every object has .metadata.namespace set to: <purpose>-<component-name>
As a default, .metadata.name is set to the Component name. Secondary objects of the same kind have appropriate names (conventions to be established).
Example: A namespace has at least two Secrets — one named after the Component (deployment configuration), and one named ghcr-secret (Docker image pull credentials). If a Component deploys multiple Modules requiring different secrets, they are named after their Module.
Copyright: © Arda Systems 2025-2026, All rights reserved