e41ecfad4c
Include Loyalty/Communication/Sports Center backends and registry updates alongside production nginx and compose wiring. Co-authored-by: Cursor <cursoragent@cursor.com>
2.2 KiB
2.2 KiB
ADR-011: Independent Enterprise Loyalty Platform Service
| Field | Value |
|---|---|
| Status | Accepted |
| Date | 2026-07-24 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |
Context
Multiple business modules (Restaurant, Marketplace, Ecommerce, Academy, Booking, Healthcare, Salon, Gym, and future modules) need loyalty, points, rewards, campaigns, referrals, wallets, and gift cards. Embedding loyalty inside CRM or any single business module would couple unrelated domains and prevent reuse.
Decision
Loyalty is an independent shared platform service (loyalty-service) with:
- Dedicated database
loyalty_db(ADR-001) - Permission prefix
loyalty.* - Publish-only domain events
loyalty.* - Row-level multi-tenancy via
tenant_id(ADR-003) - Immutable point ledger as the sole source of balances (Phase 7.2+) — direct balance mutation is forbidden
- Consumption by business modules via REST API + Events only — never via shared tables or CRM ownership
Loyalty must not belong to CRM, Restaurant, or Ecommerce.
Consequences
Positive
- Reusable loyalty across all business modules
- Clear ownership and independent schema evolution
- Enforceable ledger / audit invariants
Negative
- Modules must integrate asynchronously for eventual consistency of customer 360 views
- Cross-module references use external IDs / refs only
Neutral
- Phase 7.0 ships foundation aggregates; engines (membership, points, rewards, campaigns, referral, wallet, gift card, analytics, public APIs) land in Phases 7.1–7.9
Alternatives Considered
- Loyalty subsystem inside CRM — rejected (CRM is Sales-only; Loyalty is cross-module)
- Per-module loyalty tables — rejected (duplication, inconsistent rules)
- Shared monolith database schema — rejected (ADR-001)