morteza/TorbatYar
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
ef048219cd
TorbatYar/docs/architecture/adr/ADR-016.md
Mortezakoohjani 203671a7bf feat(experience): ship Experience Platform phases 11.0-11.10 
Add the experience service with sites through analytics/AI hooks, migrations through 0011, and phase docs/manifests marking the track complete.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-27 11:43:10 +03:30

3.3 KiB
Raw Blame History

ADR-016: Independent Experience Platform Service

Field Value
Status Accepted
Date 2026-07-25
Deciders Platform Architecture
Supersedes —
Superseded by —

Context

Hospitality, Marketplace, Sports Center, CRM, and future verticals all need websites, landings, mini sites, menus-as-pages, catalogs, forms, and campaign surfaces. Embedding page/theme/template engines inside each vertical would duplicate logic and couple unrelated domains.

TorbatYar already isolates shared platforms as independent services (Loyalty ADR-011, Communication ADR-012, Sports Center ADR-014, Delivery ADR-015). Digital experience / page publishing needs the same independence.

Commercial product name: Torbat Pages. Prefer experience over the historical website_builder scaffold for new page/site work.

Decision

  1. Introduce experience as an independent Experience Platform service with sole ownership of experience_db (ADR-001).
  2. Permission prefix: experience.*. Publish-only domain events: experience.*.
  3. Row-level multi-tenancy via tenant_id (ADR-003).
  4. Consume Accounting, CRM, Loyalty, Communication, Storage, and vertical services only via REST API and Events — never shared tables or foreign model imports.
  5. Messaging only through Communication (ADR-012).
  6. Media binaries only via File Storage refs — no blobs in experience_db.
  7. Implementation phases are registered as Phase 11.0–11.10 in phase-manifest.yaml; roadmap in experience-roadmap.md.
  8. Product AI remains optional and external (ai-architecture.md). Core authoring/publish works when AI is off.
  9. UI builders and public shells live in frontend/ only (ADR-002); this service exposes APIs and events.

Consequences

Positive

  • One reusable experience platform for all verticals
  • No duplicated page/theme engines across Hospitality/Marketplace/etc.
  • Enforceable tenancy, audit, and boundary tests

Negative

  • Additional deployable service and database
  • Eventual consistency for cross-service published surfaces

Neutral

  • Registration (this ADR + manifests) precedes business code; Phase 11.0 implements the scaffold
  • Historical website_builder scaffold remains a pointer

Alternatives Considered

  1. Website builder inside Hospitality — rejected (blocks Marketplace/Sports reuse).
  2. Experience tables inside Core — rejected (violates ADR-001 and module boundaries).
  3. Per-vertical bespoke page stacks — rejected (duplicates logic).

Related Documents