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.

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

2.0 KiB Raw Blame History