Architecture
App Registry
Canonical model for app identity, modules, presentation metadata, and tenant/plan assignment
Decision
The app registry is the foundation of the platform.
It defines:
- what an app is
- how it is described
- which tenants include it
- how plans gate it
- which modules and capabilities it exposes
- how the app should be presented in the UI
App-level identity
The unit of entitlement is the app.
Examples:
shopcrmbookingsgiving
Internal surfaces stay inside the app:
shop.productsshop.categoriesshop.inventoryshop.orders
Those are modules, not top-level apps.
Optional product growth should be modeled as extensions, not fake apps.
Examples:
shopadvanced shippingshopreplenishment subscriptionsshopmarketplace sync
Why this matters
If internal product surfaces are promoted to apps:
- plans become noisy
- navigation becomes unstable
- app management becomes artificial
- runtime logic drifts back into complexity
The registry prevents that.
Owned metadata
The registry should own app presentation metadata such as:
- title
- short title
- navigation label
- icon key
- primary path
- switcher visibility
- sidebar visibility
- action shortcuts
Entitlement decides existence. Metadata decides presentation.
What the registry should not own
The registry should not turn shared services into apps.
These stay outside top-level app identity:
- payments
- auth
- notifications
- search
- files