Architecture
Shop Model
How `shop` should be modeled without turning internal commerce surfaces into pseudo-apps
Decision
shop remains one top-level app.
Its internal commerce capabilities stay inside the app as modules.
Core modules
The core shop app naturally includes:
- catalog
- products
- categories
- collections
- inventory
- orders
- checkout
- fulfillment
- discounts
These are part of the app's core business surface.
They should not become separate apps in the registry or in plan assignment.
Optional extensions
The following are better treated as extensions:
- replenishment subscriptions
- subscription management surface
- advanced shipping
- tax integrations
- marketplace/channel sync
- ERP or warehouse sync
This preserves one coherent shop app while still allowing optional growth.
Shared services used by shop
shop should depend on shared platform services for:
- payments
- auth
- notifications
- files/media
- search
- background jobs
That does not make those services part of the app boundary.
Plan strategy
Phase 1:
- plans entitle
shop - built-in shop modules come with the app
Later:
- selected extensions or advanced admin capabilities can be gated separately
Do not start by gating products, categories, or orders independently.