Architecture
Boundary Model
App vs module vs extension vs platform service
Canonical boundary types
The platform uses four distinct boundary types:
App
A top-level business surface.
Examples:
shopgivingcrmbookings
Module
A built-in capability inside an app.
Examples inside shop:
- catalog
- products
- categories
- inventory
- orders
- fulfillment
- discounts
Modules are part of the app. They are not first-class catalog entries.
Extension
An optional capability or integration attached to an app.
Examples:
- shop subscriptions
- advanced shipping integrations
- marketplace sync
- tax engine integration
- ERP sync
Extensions are the right place for optional product growth without exploding the app list.
Platform service
Shared infrastructure used by multiple apps.
Examples:
- payments
- auth
- notifications
- files
- search
- jobs
- tenant billing
Platform services should not be registered as top-level business apps.
Decision test
When deciding whether something is an app, ask:
- Would a tenant assign this independently?
- Would a plan sell or include this independently?
- Would a top-level nav entry make sense?
- Does it have a distinct operator workflow from its parent?
If most answers are no, it is not an app.
Registry implications
The registry owns top-level app identity only.
platform_appsholds appsplatform_app_modulesdescribes built-in slices- extension points should be modeled separately
- shared services stay outside the app registry