# 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