سوق قطع الغيار

نظرة عامة#

سوق إلكتروني متعدد المستأجرين لقطع غيار السيارات، يربط عددًا كبيرًا من التجار بعدد كبير من العملاء عبر كتالوج ومحفظة ونظام طلبات مشترك. هذا مشروع تجاري خاص قيد التطوير، لذا تركز دراسة الحالة هذه على المعمارية بدلًا من لقطات الشاشة — فالقرارات الهندسية هي الجزء الأهم.

المشكلة#

تجارة قطع الغيار تتميز بمخزون مجزأ (نفس القطعة الفعلية تُدرج بشكل مختلف من كل بائع)، وتسوية حساسة نقديًا (يحتاج التجار للثقة بأرقام المنصة)، وتكاملات اختيارية (بوابات دفع، أنظمة ERP، إشعارات واتساب) لا ينبغي أن يؤدي فشلها أو عدم تهيئتها لمستأجر معين إلى تعطيل النظام الأساسي.

الحل#

النظام الخلفي بنمط Modular-Monolith بواسطة NestJS، منظّم وفق Clean Architecture / DDD: لكل وحدة طبقاتها الخاصة domain / application / infrastructure / presentation بحدود صارمة، وكل تكامل خارجي اختياري يقع خلف طبقة عزل (Anti-Corruption Layer) بحيث يعمل السوق الأساسي بشكل مستقل تمامًا عن توفر أي خدمة خارجية. من الناحية المالية، النظام قائم على دفتر الأستاذ أولًا: أرصدة المحفظة والمخزون لا تُعامل أبدًا كأرقام قابلة للتعديل المباشر — بل تُشتق من دفاتر أستاذ بنمط الإضافة فقط، وهذا ما يجعل الأرقام قابلة للتدقيق ويجعل نصوص الاسترجاع الآلي ممكنة.

المعمارية#

تتواصل ثلاث لوحات تحكم بـ Next.js (إدارة، تاجر، عميل) وتطبيق Flutter للعملاء مع نفس واجهة NestJS البرمجية، وتتشارك حزمة نظام تصميم موحدة على جانب الويب. تُبث الحالة اللحظية — حالة الطلب، رصيد المحفظة، إشعارات التاجر — عبر WebSockets بدلًا من الاستطلاع الدوري. تُعد PostgreSQL (عبر Prisma) مصدر الحقيقة الرئيسي؛ ويتولى Redis وBullMQ المهام الخلفية، من حساب العمولات إلى المهمة المجدولة التي تُشغّل نظام التوصيات.

الميزات#

• محفظة ومخزون قائمان على دفتر الأستاذ — دفاتر أستاذ بنمط الإضافة فقط كمصدر وحيد للحقيقة، مع محرك عمولات قائم على القواعد قابل للتحديد حسب الفئة أو العلامة التجارية أو المتجر.
• سير عمل سحب قابل للتدقيق — متعدد الحالات، مع توليد فواتير آلي، وترقيم تسلسلي، وتحقق استلام عبر QR.
• آلة حالات كاملة لدورة حياة الطلب — تأكيد التاجر ← الدفع ← التجهيز ← الاستلام، مع معالجة آلية للمهل الزمنية، وسير عمل لحل النزاعات، واسترداد جزئي/كامل مع توليد إشعارات دائن.
• بحث منتجات مرتّب عبر التجار — إزالة تكرار القطع الأصلية بين البائعين، وتصفية حسب توافق المركبة، وبحث متعدد الأوجه.
• توصيات — منتجات تُشترى معًا بكثرة وقطع بديلة/متوافقة، مبنية على تحليلات فعلية لسجل الشراء تُحسب عبر مهمة دفعية مجدولة.
• أدوات سلامة البيانات — نصوص آلية وقابلة للتكرار للتحقق من التطابق والإصلاح، تتحقق باستمرار من أن الأرصدة والمخزون والفواتير المخزّنة مؤقتًا تُطابق دفاتر الأستاذ المرجعية.

عملية التطوير#

جاءت المعمارية أولًا: تم تحديد حدود النطاقات وطبقة العزل قبل ربط أي تكامل، تحديدًا لكي يمكن إضافة المدفوعات وERP وواتساب أو استبدالها أو تعطيلها لكل مستأجر دون المساس بمنطق الطلبات أو المحفظة الأساسي. بُنيت أدوات سلامة البيانات جنبًا إلى جنب مع نظام دفتر الأستاذ منذ اليوم الأول بدلًا من إضافتها لاحقًا بعد اكتشاف تباين في الإنتاج.

التحديات#

الحفاظ على اتساق ثلاث واجهات أمامية منفصلة (إدارة، تاجر، عميل) أثناء التكرار السريع تطلّب استثمارًا مبكرًا في حزمة نظام تصميم مشتركة بدلًا من ترك كل لوحة تحكم تنحرف عن الأخرى. وتطلّب ضبط آلة حالات الطلب بشكل صحيح — خاصة تفاعل المهل الزمنية والاسترداد الجزئي مع دفتر الأستاذ — نمذجة كل انتقال حالة بشكل صريح بدلًا من الاعتماد على حقول حالة ضمنية.

النتائج#

سوق إلكتروني إنتاجي بثلاث لوحات تحكم فعّالة، وتحديثات لحظية للطلبات والمحفظة عبر WebSocket، ونواة مالية تُصحح نفسها تلقائيًا بدلًا من الاعتماد على تدقيق يدوي.

تحسينات مستقبلية#

توسيع طبقة العزل لدعم مزودي دفع إضافيين حسب المنطقة، وتوسيع محرك التوصيات بإضافة تصفية تعاونية (Collaborative Filtering) فوق تحليلات سجل الشراء الحالية.