ADR-016 — Variant Editor Section Architecture & Tab Registry

Context

The planDetails (country variant) structure across SVOD and TVOD contains numerous fields grouped into different business concerns:

• Variant identity
• Payment configuration
• Pricing model
• Availability
• Marketing
• Terms & Conditions

Initially, fields were rendered in a flat structure, which increased cognitive load and risked conditional sprawl as plan types diverged.

There was also a need to:

• Isolate domain concerns within the variant editor
• Avoid monolithic conditional rendering
• Enable modular section ownership
• Support lazy loading per section

Decision

We introduced a section-based Variant Editor architecture structured as:

addOrEditVariant/
  ├── index.tsx
  └── tabs/
      ├── core
      ├── payment-settings
      ├── pricing
      ├── availability-access
      ├── marketing
      └── tnc

Each section:

• Owns its domain concern
• Is dynamically imported
• Is rendered via an accordion in index.tsx
• Does not contain cross-domain logic

A static PlanDetailTabsRegistry was introduced as a single source of truth:

export const PlanDetailTabsRegistry = {
  core: { title, render },
  payment-settings: { title, render },
  pricing: { title, render },
  availability-access: { title, render },
  marketing: { title, render },
  tnc: { title, render },
}

This registry:

• Is static and declarative
• Contains no business logic
• Controls ordering and dynamic imports
• Is the only authority for variant section structure

Consequences

Positive

• Clear domain separation inside variant editor
• Reduced cognitive load in large forms
• Lazy-loaded sections improve maintainability
• No monolithic form file
• Sections can evolve independently
• Architecture supports stable monetisation domain

Negative

• Slight increase in file count

Notes

• This ADR establishes a stable structural foundation for all future plan types.
• The registry is strictly configuration-only and must not contain conditional or business logic.