76 lines
2.0 KiB
Markdown
76 lines
2.0 KiB
Markdown
|
# Config Domain
|
||
|
|
|
||
|
|
## 1. Purpose
|
||
|
|
CONFIG DOMAIN provides runtime UI configuration for a tenant.
|
||
|
|
It enables one frontend build to serve many tenants by changing configuration, not code.
|
||
|
|
|
||
|
|
Primary outputs:
|
||
|
|
- `/bootstrap`
|
||
|
|
- `/pages/:slug` (static content domain)
|
||
|
|
|
||
|
|
## 2. Ownership
|
||
|
|
Config domain owns:
|
||
|
|
- tenant public runtime metadata
|
||
|
|
- theme and visual tokens
|
||
|
|
- layout mode and page structure
|
||
|
|
- widget registry metadata pointers
|
||
|
|
- footer metadata and legal-page mapping
|
||
|
|
- feature flags and localization mappings
|
||
|
|
|
||
|
|
Business domain owns:
|
||
|
|
- items, categories, cart, orders, payments, auth
|
||
|
|
|
||
|
|
## 3. Layout Engine Responsibility
|
||
|
|
Backend returns layout intent (e.g., `layout.type`) and page graph.
|
||
|
|
Frontend layout engine composes UI from this graph.
|
||
|
|
|
||
|
|
Supported modes:
|
||
|
|
- default
|
||
|
|
- sidebar-left
|
||
|
|
- carousel-home
|
||
|
|
- minimal
|
||
|
|
|
||
|
|
No tenant-specific UI branching in component code.
|
||
|
|
|
||
|
|
## 4. Widget Registry Concept
|
||
|
|
Backend provides `widgetRegistry.manifestUrl`.
|
||
|
|
Frontend reads manifest and resolves approved widget keys.
|
||
|
|
|
||
|
|
Benefits:
|
||
|
|
- controlled extensibility
|
||
|
|
- unknown widget safe fallback
|
||
|
|
- decoupled rollout of widget metadata
|
||
|
|
|
||
|
|
## 5. Footer + Static Page System
|
||
|
|
Footer metadata includes:
|
||
|
|
- columns and links
|
||
|
|
- payment icons
|
||
|
|
- legal page references
|
||
|
|
- localized copyright
|
||
|
|
|
||
|
|
Static pages provide multilingual HTML per slug.
|
||
|
|
Frontend renders through safe sanitization path.
|
||
|
|
|
||
|
|
## 6. Feature Flags
|
||
|
|
Feature flags in bootstrap:
|
||
|
|
- enable/disable capabilities at tenant scope
|
||
|
|
- support gradual rollout
|
||
|
|
- avoid deployment-based behavior switches
|
||
|
|
|
||
|
|
## 7. Config Data vs Business Data
|
||
|
|
Config data:
|
||
|
|
- shapes the interface
|
||
|
|
- relatively low-frequency changes
|
||
|
|
- public-safe payloads
|
||
|
|
|
||
|
|
Business data:
|
||
|
|
- transactional/catalog state
|
||
|
|
- high-frequency updates
|
||
|
|
- operational integrity requirements
|
||
|
|
|
||
|
|
## 8. Why Separation Matters
|
||
|
|
- scalability: independent lifecycle for UI config and business operations
|
||
|
|
- safety: prevents leaking operational logic into UI composition
|
||
|
|
- maintainability: clear boundaries and lower coupling
|
||
|
|
- multi-tenant readiness: behavior changes per tenant without code fork
|