# معماری دیتابیس NOVA Beauty OS

## اصل معماری

یک دیتابیس مشترک برای تمام سالن‌ها استفاده می‌شود. جداول عملیاتی دارای `salon_id` هستند. یک فرد فقط یک رکورد در `users` دارد، اما می‌تواند در چند سالن مشتری، متخصص یا مدیر باشد.

## هویت و دسترسی

- `users`: هویت سراسری بر اساس شماره موبایل
- `mobile_login_codes`: OTP آزمایشی و بعداً پیامکی
- `salon_user`: نقش‌های owner، manager، receptionist، accountant و specialist
- `salon_invitations`: دعوت پرسنل یا متخصص با شماره موبایل

## پلتفرم و اشتراک

- `plans`
- `salons`
- `salon_settings`
- `branches`
- `subscriptions`
- `subscription_payments`

پلن `Solo` یک متخصص فعال و یک شعبه دارد. پلن `Salon` متخصص نامحدود و یک شعبه دارد. پلن چندشعبه‌ای در آینده بر اساس `max_branches` اضافه می‌شود.

## کاتالوگ خدمات

- `service_categories`: دسته‌هایی مثل مو، ناخن و مژه
- `services`: تخصص‌هایی مثل کاشت ناخن یا رنگ مو
- `service_variants`: مدل دقیق مثل کاشت پودر، بالیاژ یا مگاوالیوم

هر سه جدول دارای تصویر هستند و توسط سوپرادمین مدیریت می‌شوند.

## متخصص

- `specialist_profiles`: پروفایل عمومی فرد متخصص
- `salon_specialists`: ارتباط متخصص با یک سالن و قوانین پورسانت آن سالن
- `specialist_branches`: شعب محل فعالیت
- `specialist_services`: تخصص‌های انتخاب‌شده
- `specialist_service_variants`: مدل‌های قابل ارائه، قیمت، زمان و بیعانه هر متخصص
- `work_schedules`: ساعات کاری و شیفت‌های چندگانه
- `specialist_time_off`: مرخصی و زمان مسدود

## مشتری

- `salon_customers`: پرونده مستقل مشتری در هر سالن
- `customer_notes`: یادداشت‌های تاریخچه‌دار با سطح نمایش

یک `user` می‌تواند چند رکورد در `salon_customers` داشته باشد؛ هر رکورد متعلق به یک سالن است.

## رزرو

- `appointments`
- `appointment_status_histories`

رزرو شامل مدل خدمت، متخصص، قیمت، زمان، وضعیت پرداخت و Snapshot نام مشتری، متخصص و خدمت است. کنترل تداخل باید بر اساس `user_id` متخصص در تمام سالن‌ها انجام شود.

## فروش و مالی

- `product_categories`
- `products`
- `inventory_movements`
- `orders`
- `order_items`
- `payments`
- `commission_entries`
- `commission_settlements`
- `commission_settlement_items`

`commission_entries` پورسانت قطعی هر خدمت را ثبت می‌کند؛ بنابراین تغییر درصد پورسانت در آینده روی تاریخچه اثر نمی‌گذارد.

## ارتباط با مشتری

- `loyalty_programs`
- `loyalty_transactions`
- `loyalty_rewards`
- `loyalty_redemptions`
- `feedback`
- `before_after_photos`
- `campaigns`
- `campaign_customers`

کمپین فعلاً کانال `manual` دارد و هیچ سرویس پیامکی به آن متصل نیست.

## امنیت و عملیات

- `audit_logs`: ثبت تغییرات حساس
- `notifications`: اعلان داخل برنامه
- `jobs`, `failed_jobs`, `job_batches`: صف Laravel
- `cache`, `cache_locks`: Cache دیتابیسی در صورت نیاز

## Tenant Scope

Modelهای وابسته به سالن از Trait زیر استفاده می‌کنند:

```text
App\Models\Concerns\BelongsToSalon
```

این Trait در صورتی که `currentSalon` توسط Middleware مشخص شده باشد، `salon_id` را خودکار روی Query و Insert اعمال می‌کند.

برای Queryهای سراسری واقعی، مانند کنترل تداخل متخصص بین چند سالن، Scope باید صریحاً حذف شود:

```php
Appointment::withoutGlobalScope(SalonScope::class)
```

## ترتیب ساخت داده

1. User
2. Plan
3. Salon
4. Branch و Salon Membership
5. Subscription
6. Catalog
7. Specialist و Customer
8. Specialist Service Pricing
9. Appointment
10. Payment، Commission و Loyalty