XigmaHardware — پلتفرم فروش و عملیات تجهیزات سخت‌افزاری

معرفی پروژه

XigmaHardware یک فروشگاه عمومی ساده نیست؛ پروژه به‌عنوان یک Commerce Operations Platform برای فروش تخصصی سخت‌افزار طراحی شده است. دامنه‌ی محصول از قطعات PC و تجهیزات خانگی تا سرور، ورک‌استیشن، قطعات سازمانی و تجهیزات دیتاسنتر امتداد دارد و به همین دلیل کاتالوگ، موجودی، قیمت‌گذاری، پرداخت و لجستیک باید مانند یک سیستم عملیاتی واحد رفتار کنند.

پروژه پس از ۷ ماه توسعه فعال به ۷۵٪ پیشرفت رسیده است. هسته‌ی فنی، مارکت، کاتالوگ و انبار، پروفایل مشتری، پشتیبانی، داشبوردهای عملیاتی و بخش عمده‌ی جریان مالی/لجستیک پیاده شده‌اند؛ ۲۵٪ باقی‌مانده بیشتر به hardening انتهای زنجیره‌ی سفارش تا ارسال، پوشش تست گسترده‌تر، پایدارسازی کامل درگاه‌ها و polish نهایی پنل‌های عملیاتی مربوط است.

مسئله‌ای که پلتفرم حل می‌کند

فروش سخت‌افزار حرفه‌ای با یک فروشگاه معمولی متفاوت است. یک کالا ممکن است در چند انبار باشد، بخشی از موجودی برای سفارش رزرو شده باشد، تنها سهم مشخصی برای فروش آنلاین تخصیص داده شود، قیمت مارکت با قیمت پایه فرق کند و مشتری نیز به مشخصات فنی، برند، سری، مدل، پارت‌نامبر و وضعیت نو/کارکرده حساس باشد.

در طرف عملیات نیز فروش بدون حسابداری، فاکتور، درگاه پرداخت، تحویل و خدمات پس از فروش کامل نیست. هدف XigmaHardware این است که این جریان‌ها را در یک سامانه به هم متصل کند تا «موجودی واقعی»، «چیزی که در سایت نمایش داده می‌شود» و «چیزی که واقعاً قابل فروش و ارسال است» از هم جدا نشوند.

معماری دامنه

Backend به domainهای مستقل تقسیم شده است:

• Accounts — هویت، پروفایل، OTP، امنیت، کیف پول و نقش‌های سیستم
• Admin Panel — API عمومی مدیریت مدل‌های قابل کنترل از پنل سفارشی
• Stock — دسته‌بندی، برند، سری، Product، Warehouse و Inventory
• Market — صفحه‌ی فروش محصول، Media، Review، قیمت و موجودی قابل عرضه
• Basket — سبد خرید و Wishlist
• Financial — تراکنش، فاکتور، اسناد و تنظیمات مالی
• Payment — abstraction درگاه و اتصال به ZarinPal / PayPing
• Logistics — Address، Neshan، Courier، Shipment و وضعیت تحویل
• Support — Ticket، Guest Chat و Realtime WebSocket
• Website — تنظیمات و محتوای وب‌سایت

این مرزبندی باعث می‌شود صفحه‌ی فروشگاه مستقیماً مالک موجودی یا انبار نباشد و هر domain مسئول حقیقت خودش باقی بماند.

جریان انتشار کالا؛ از کاتالوگ تا مارکت

یکی از نقاط مهم طراحی، جدا کردن هویت کالا از صفحه‌ی قابل فروش کالا است. جریان استاندارد انتشار به شکل زیر است:

Product
  ↓
Warehouse
  ↓
Inventory Item
  ↓
Market allocation on Product
  ↓
Market Product

stock.Product هویت، مشخصات فنی، SKU، برند/سری، قیمت پایه و محدودیت‌های عرضه را نگه می‌دارد. InventoryItem مشخص می‌کند از آن Product در کدام Warehouse چه مقدار موجود و چه مقدار رزرو شده است. MarketProduct لایه‌ی فروشگاهی است: عنوان بازاری، توضیحات، SEO، Media، قیمت و محدودیت سفارش.

موجودی آزاد فیزیکی از رابطه‌ی زیر محاسبه می‌شود:

available_quantity = quantity - reserved_quantity

و سقف واقعی فروش آنلاین از حداقل موجودی آزاد و سهمی که Product برای مارکت تخصیص داده به دست می‌آید. بنابراین افزایش موجودی انبار به‌تنهایی یک محصول را ناخواسته منتشر نمی‌کند.

کاتالوگ تخصصی سخت‌افزار

ساختار Stock برای کالاهای فنی طراحی شده است: دسته‌بندی‌های چندسطحی، برند، سری، مدل، پارت‌نامبر، وضعیت کالا، مشخصات فنی، تصاویر و داده‌های قیمت. Seed نمونه نیز چهار خانواده‌ی اصلی دیتاسنتر، سازمانی/اداری، خانگی و ورک‌استیشن را همراه با زیرشاخه‌ها و محصولات نمونه ایجاد می‌کند.

این ساختار اجازه می‌دهد پنل مدیریت قبل از انتشار یک محصول، ابتدا داده‌ی فنی و انبار را کامل کند و بعد آن را وارد Market کند؛ رویکردی که برای کالاهای حرفه‌ای بسیار قابل‌اعتمادتر از ساخت مستقیم «محصول فروشگاهی» است.

مارکت، جست‌وجو و تجربه خرید

Frontend بر پایه Next.js 16 و React 19 ساخته شده و Market، Product Detail، Product Card و Review به‌صورت مستقل پیاده شده‌اند. محصول می‌تواند حتی هنگام ناموجود شدن در مارکت باقی بماند و وضعیت «ناموجود» نمایش داده شود؛ در نتیجه URL و SEO محصول به‌خاطر صفر شدن موجودی از بین نمی‌رود.

کاربر می‌تواند محصولات را مرور کند، جزئیات و مشخصات را ببیند، Wishlist داشته باشد و کالا را وارد سبد کند. Context سبد با وضعیت احراز هویت هماهنگ می‌شود تا تجربه‌ی کاربر از صفحه‌ی عمومی تا Checkout یکپارچه بماند.

پروفایل مشتری و حساب کاربری

پروفایل کاربر برای بازار ایران طراحی شده است:

• حساب حقیقی یا حقوقی
• اطلاعات فردی/شرکتی
• تأیید ایمیل و موبایل
• OTP برای ثبت‌نام، ورود، تغییر اطلاعات و بازیابی رمز
• تاریخ شمسی در رابط کاربری
• مدیریت آدرس‌ها
• کیف پول و تاریخچه تراکنش
• مشاهده فاکتورها
• طراحی Light/Dark

در سطح امنیت، single-session نیز در foundation branch توسعه داده شده تا نشست فعال کاربر قابل کنترل باشد و رفتار login فقط به صدور خام JWT محدود نماند.

نقش‌ها و Backoffice

XigmaHardware چند نقش عملیاتی دارد:

• Super Admin — دسترسی کامل
• Accountant — مالی، تراکنش‌ها، فاکتور و درگاه‌ها
• Logistics — مدیریت ارسال و عملیات لجستیک
• Courier — عملیات تحویل
• Stock Keeper — انبار و موجودی
• Helpdesk — Ticket و Chat
• Client — مشتری فروشگاه

Header و menu بر اساس دسترسی طراحی شده‌اند تا کاربران غیرمرتبط به داشبوردهای سازمانی دسترسی یا حتی گزینه‌ی غیرضروری در UI نداشته باشند.

پنل ادمین سفارشی

به‌جای وابستگی کامل به Django Admin، یک Admin Panel API و رابط /pannel-admin وجود دارد. registry مدل‌های مجاز، serializerهای عمومی، permission و CRUDهای قابل کنترل از فرانت را مدیریت می‌کنند. این ساختار کمک می‌کند تیم عملیات با UI فارسی و سازگار با workflow واقعی کار کند، در حالی‌که منطق مجوز همچنان در backend باقی می‌ماند.

برای مارکت نیز میزکار جداگانه‌ای توسعه داده شده تا فرآیند Product → Stock → Market به یک workflow قابل فهم برای اپراتور تبدیل شود.

مالی، فاکتور و اسناد

ماژول Financial فقط «ثبت تراکنش» نیست. ساختار فعلی شامل داشبورد حسابداری، فاکتور، تنظیمات سند و تولید PDF است. مدیر مالی می‌تواند اطلاعات شرکتی مربوط به سند، لوگو، مهر و امضا را مدیریت کند و سیستم برای پیش‌فاکتور، فاکتور نهایی و اسناد شارژ کیف پول خروجی تولید کند.

پس از نهایی شدن سفارش، اعلان‌ها و اسناد مالی می‌توانند از طریق taskهای Celery ارسال شوند تا تولید PDF و ایمیل، request اصلی کاربر را بلاک نکنند.

پرداخت آنلاین

لایه‌ی Payment با abstraction جداگانه طراحی شده و درگاه‌های ZarinPal و PayPing را پوشش می‌دهد. تنظیمات درگاه از منطق سفارش جداست و مدیریت درگاه‌ها در Backoffice قابل کنترل است. ZarinPal حالت Sandbox و Production و verify مستقل دارد.

یکی از بخش‌های باقی‌مانده‌ی پروژه، hardening کامل تمام سناریوهای واقعی providerها، callbackها و failure/retry در محیط production است؛ بنابراین در این Case Study عمداً پرداخت را «کاملاً نهایی‌شده» معرفی نمی‌کنیم.

لجستیک مبتنی بر موقعیت

آدرس فقط یک فیلد متنی نیست. Neshan در backend برای reverse geocode و اعتبارسنجی مختصات استفاده می‌شود و در frontend کاربر می‌تواند نقطه‌ی واقعی را روی نقشه انتخاب کند.

روش‌های تحویل شامل:

• پیک تهران
• پست
• تیپاکس
• چاپار

است و مدل Shipment چرخه‌هایی مانند Pending، Assigned، Picked Up، In Transit، Delivered، Returned و Cancelled را پوشش می‌دهد. Dashboard لجستیک نیز برای کاربران Logistics/Courier طراحی شده است.

پشتیبانی و ارتباط بلادرنگ

Support به دو مسیر اصلی تقسیم می‌شود: Ticketing برای پیگیری ساختاریافته و Live Chat برای ارتباط سریع. Guest Chat نیز پشتیبانی می‌شود تا بازدیدکننده‌ی بدون حساب بتواند پیش از خرید سؤال بپرسد.

Realtime روی Django Channels/WebSocket پیاده شده و endpointهای عمومی حساس با throttling محافظت می‌شوند. نتیجه این است که Helpdesk یک میزکار واقعی دارد، نه صرفاً یک فرم «تماس با ما».

رسانه و Object Storage

عکس و ویدئوی کالا از فایل‌های static برنامه جدا شده‌اند و MinIO به‌عنوان object storage در معماری قرار گرفته است. محیط‌های dev/stage/prod از Docker Compose مستقل استفاده می‌کنند و سرویس‌های PostgreSQL، Redis، backend، worker، storage، frontend و Nginx به‌صورت قابل‌استقرار تعریف شده‌اند.

کیفیت، تست و DevOps

foundation branch یک مرحله‌ی مهم تثبیت مهندسی بوده است:

• تفکیک settings و environmentها
• Docker Compose برای dev / test / stage / prod
• CI روی GitHub Actions
• Pytest برای backend
• lint/build برای frontend
• تست‌های اختصاصی برای Auth، single-session، Market Product API، Market Management، Neshan logistics، Accounting Dashboard، Invoice Documents، Payment Verify و Support Realtime
• حذف secretهای hard-coded و انتقال کلیدها به env
• same-origin API در production از طریق Nginx

این فاز پروژه را از یک prototype سریع به پایه‌ای قابل ادامه برای production نزدیک کرده است.

نقاط قوت مهندسی

تفکیک Catalog از Marketplace

Stock مالک حقیقت فنی و فیزیکی کالاست و Market مالک نمایش فروشگاهی. این مرز از ناسازگاری موجودی، انتشار ناخواسته و coupling شدید جلوگیری می‌کند.

موجودی رزروشده و سهم مارکت

فروشگاه موجودی فیزیکی را مستقیماً «قابل فروش» فرض نمی‌کند؛ رزرو سفارش و سهم تخصیص‌یافته به مارکت در تصمیم فروش مؤثرند.

Backoffice مبتنی بر نقش

مالی، انبار، لجستیک، پیک و Helpdesk workflow و سطح دسترسی متفاوت دارند و همه مجبور نیستند با یک پنل عمومی مشترک کار کنند.

Persian-first UX

تقویم جلالی، پیام‌های validation فارسی، قالب قیمت، مدیریت آدرس و روش‌های ارسال محلی از ابتدا جزو معماری محصول بوده‌اند؛ نه patch بعد از پایان توسعه.

Async و Realtime در جای درست

Celery برای taskهای ایمیل/اعلان و Channels برای Chat استفاده شده‌اند؛ یعنی کارهای کند و ارتباط بلادرنگ از request/response عادی جدا شده‌اند.

ارزش برای کسب‌وکار سخت‌افزار

نیاز کسب‌وکار	پاسخ XigmaHardware
کاتالوگ بزرگ و فنی	دسته، برند، سری، SKU، مدل، پارت‌نامبر و مشخصات
جلوگیری از فروش بیش از موجودی	Inventory + reserved quantity + market allocation
چند انبار	Warehouse و InventoryItem مستقل
فروش آنلاین بدون از دست دادن کنترل انبار	مرحله‌ی انتشار جداگانه Product → MarketProduct
فروش B2C/B2B	پروفایل حقیقی/حقوقی و اسناد مالی
عملیات مالی	تراکنش، کیف پول، فاکتور، PDF، تنظیمات سند
پرداخت ایران	ZarinPal و PayPing با abstraction درگاه
ارسال محلی و بین‌شهری	Neshan + Courier/Post/Tipax/Chapar
خدمات مشتری	Ticket + Live Chat + Helpdesk Dashboard
رشد تیم عملیاتی	Role-aware admin/accounting/logistics/support workspaces

فناوری‌ها

Backend: Django 5، Django REST Framework، PostgreSQL 16، Redis 7، Celery، Channels، SimpleJWT

Frontend: Next.js 16، React 19، Emotion، React Hook Form، Jalali date UI

Infrastructure: Docker Compose، Nginx، Gunicorn، MinIO، GitHub Actions

Integrations: Neshan، ZarinPal، PayPing، SMTP/Email

وضعیت فعلی — ۷۵٪

هسته‌ی پلتفرم، foundation، حساب کاربری، کاتالوگ و انبار، مارکت، wishlist، بخش عمده‌ی checkout، داشبوردهای Admin/Accounting/Logistics/Support، Neshan، فاکتور و realtime support توسعه یافته‌اند.

۲۵٪ باقی‌مانده

کار باقی‌مانده بیشتر در این محورهای production-readiness قرار دارد:

1. بستن کامل جریان Order → Payment → Verification → Invoice → Shipment → Delivery با تست end-to-end
2. hardening providerهای پرداخت و سناریوهای callback/retry/failure واقعی
3. افزایش پوشش تست domainهای قدیمی‌تر و تست integration بین مالی/لجستیک/سبد
4. polish نهایی CRUDها و UX پنل‌های عملیاتی
5. تکمیل اعلان‌های چندکاناله و سناریوهای edge در سفارش و ارسال
6. observability، مانیتورینگ و acceptance test نهایی محیط production

این ۲۵٪ بیشتر تثبیت و تکمیل زنجیره‌ی عملیاتی است تا ساخت دوباره‌ی معماری اصلی؛ یعنی ستون‌های محصول در جای خود قرار گرفته‌اند و کار بعدی روی قابل‌اعتماد کردن کل مسیر برای استفاده‌ی production متمرکز است.