morteza/TorbatYar
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
72077908f1
TorbatYar/docs/architecture/adr/ADR-017.md
Mortezakoohjani 5c6a2e78cf feat(platform): seed service registry, deploy all modules, and fix homepage catalog. 
Register all active platform services and base features in core DB so admin can manage them, add delivery/hospitality/sports-center backend phases, update apps catalog and production deploy tooling.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-27 12:39:51 +03:30

4.2 KiB
Raw Blame History

ADR-017: Independent Hospitality Platform Service

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

Context

Cafes, coffee shops, restaurants, fast food, bakeries, pastry shops, ice cream and juice bars, cloud kitchens, food courts, catering, and take-away all need shared operational capabilities (venues, menus, tables, POS connectors, kitchen, reservations, delivery connectors). Embedding this inside CRM, Loyalty, Accounting, Delivery, Experience, or Sports Center would couple unrelated domains and block reuse.

TorbatYar already isolates shared platforms as independent services (Loyalty ADR-011, Communication ADR-012, Sports Center ADR-014, Delivery ADR-015, Experience ADR-016). Food & beverage operations need the same independence with feature-based bundles and capability discovery.

Commercial product name: Torbat Food.

The historical restaurant scaffold / restaurant-foundation phase ID is evolved into the Hospitality Platform (hospitality, Phase 12.x).

Decision

  1. Introduce hospitality as an independent Hospitality Platform service with sole ownership of hospitality_db (ADR-001).
  2. Permission prefix: hospitality.*. Publish-only domain events: hospitality.*.
  3. Row-level multi-tenancy via tenant_id (ADR-003).
  4. Feature-based architecture with bundle-based licensing, capability discovery, feature toggles, and permission gating. Hidden bundles must not expose APIs, menus, or permissions.
  5. Venue formats are configurable catalog values (cafe, restaurant, bakery, …) — never hardcoded format-specific engines in foundation.
  6. Consume Accounting, CRM, Loyalty, Communication, Delivery, Experience / Website Builder, and AI only via REST API and Events — never shared tables or foreign model imports.
  7. Financial journals only through Accounting Posting Engine (ADR-010).
  8. Messaging only through Communication (ADR-012).
  9. Loyalty points/rewards only through Loyalty (ADR-011).
  10. Last-mile logistics only through Delivery (ADR-015).
  11. Public page shells only through Experience (ADR-016) when websites/menus-as-pages are required.
  12. Implementation phases are registered as Phase 12.0+ in phase-manifest.yaml; roadmap in hospitality-roadmap.md.
  13. Product AI remains optional and external (ai-architecture.md). Core hospitality flows work when AI is off.

Consequences

Positive

  • Clear ownership for F&B / hospitality operations
  • Bundle licensing enables SMB → enterprise packaging (Digital Menu → POS Pro → Kitchen)
  • Reusable integrations with platform services

Negative

  • Additional deployable service and database
  • Eventual consistency for cross-service customer / order views

Neutral

  • Historical backend/services/restaurant README remains a pointer; runtime lives under backend/services/hospitality

Alternatives Considered

  1. Keep a narrow Restaurant-only service — rejected (blocks bakery/cloud kitchen/food court reuse).
  2. Hospitality tables inside Core — rejected (violates ADR-001 and module boundaries).
  3. Embed menus inside CRM — rejected (CRM is Sales-only).
  4. Embed operational POS inside Experience — rejected (Experience owns pages/themes, not F&B operations).

Related Documents