ما بنيناه ولماذا
بنينا نظام Laravel يربط متجراً إلكترونياً يخدم أكثر من 300,000 عميل بنظام محاسبته ومنصة الفوترة الإلكترونية، فأصبح أكثر من 1,000 طلب يومياً في الذروة يُعالَج ويُفوتَر آلياً.
التحدي
الوضع التشغيلي كما وجدناه قبل أن نكتب سطراً واحداً.
متجر إلكتروني كبير يخدم قاعدة تتجاوز 300,000 عميل ، ويعالج في الذروة أكثر من 1,000 طلب يومياً . الطلبات تُنشأ على المتجر، ثم يعيد موظفون إدخالها في نظام المحاسبة، ثم تُصدر الفواتير وتُرسل إلى منصة الفوترة الإلكترونية الحكومية.
عند هذا الحجم، الإدخال اليدوي لم يعد بطيئاً فحسب — بل صار مصدر خطأ منهجي. الفاتورة تصدر أحياناً بسعر يختلف عن سعر الطلب الفعلي بسبب الخصومات والعروض، والمرتجعات تتأخر، والامتثال الضريبي يعتمد على ألّا ينسى أحد خطوة.
قبل
- موظفون يعيدون إدخال كل طلب في نظام المحاسبة يدوياً
- فواتير تصدر بأسعار تخالف الطلب بسبب الخصومات والعروض
- الامتثال الضريبي معلّق على ألّا ينسى موظف خطوة
بعد
- أكثر من 1,000 طلب يومياً في الذروة تُعالَج وتُفوتَر دون تدخّل
- توافق الفواتير مع أسعار الطلبات الفعلية بما فيها الخصومات
- التزام مستمر بمتطلبات الفوترة الإلكترونية بلا خطوة يدوية
كيف عملنا على هذا النظام
المسار نفسه في كل مشروع نبنيه — يتغيّر محتواه لا ترتيبه.
تحليل العمل
نجلس مع من يستخدم النظام يومياً، ونرسم المسار الفعلي بكل استثناءاته — وهي غالباً سبب تعثّر المشاريع لاحقاً.
تصميم المعمارية
نموذج البيانات ومصفوفة الصلاحيات ونقاط التكامل وسلوك النظام تحت الحِمل — تُحسم قبل أي واجهة.
التطوير
بناء على مراحل قابلة للاستخدام. كل مرحلة تدخل الخدمة عاملةً، فيُصحَّح المسار مبكراً وبكلفة أقل.
التكامل
ربط النظام بما حوله — محاسبة ودفع وجهات خارجية — بطبقة لا تنكسر عند أول تعطّل في الطرف الآخر.
التحسين والتشغيل
قياس الأداء تحت حِمل حقيقي، ثم تشغيل ومراقبة وصيانة تمتدّ بعد التسليم لا تنتهي به.
الحل بوحداته
ما بنيناه فعلاً، مفصّلاً بالوحدة لا موصوفاً بعبارة عامة.
مزامنة الطلبات آلياً
من المتجر إلى نظام المحاسبة لحظة إتمام الطلب، دون تدخل بشري
إصدار الفواتير والمرتجعات وسندات القبض
آلياً بما يطابق حركة المتجر
الإرسال إلى منصة الفوترة الإلكترونية الحكومية
ومتابعة حالة كل فاتورة حتى القبول
اعتماد أسعار المتجر الأصلية
مصدراً وحيداً للحقيقة، فتنعكس الخصومات والعروض في الفاتورة بدقة — وكان هذا سبب أغلب الفروقات السابقة
معالجة المرتجعات
وإصدار إشعارات دائن مرتبطة بالفاتورة الأصلية
تقارير أداء الموظفين
مبنية على بيانات الطلبات الفعلية
لوحة مراقبة للمزامنة
تُظهر ما نجح وما فشل ولماذا، مع إعادة تشغيل أي عملية دون تدخل مطوّر
المعمارية التقنية
الطبقات كما بُنيت فعلاً في هذا النظام — من قناة المستخدم إلى البنية التي تشغّله.
واجهات برمجية أولاً
كل طبقة تتحدّث إلى ما فوقها عبر واجهة موثّقة، فإضافة قناة جديدة لاحقاً لا تعني إعادة بناء ما تحتها.
الأمان بين الطبقات
الصلاحيات تُفحص في طبقة الأعمال لا في الواجهة، وسجلّ التدقيق يوثّق كل عملية تغيّر بيانات.
أداء تحت الحِمل
العمليات الثقيلة تُدفع إلى طوابير خلفية، والقراءات الأكثر تكراراً تُخزَّن مؤقتاً، فتبقى مسارات المستخدم سريعة في الذروة.
التقنيات ولماذا اخترناها
نختار الأداة بحسب ما يجب أن تتصل به وما يجب أن تصمد أمامه — لا بحسب ما هو رائج هذا العام.
هندسة الخلفية Backend
طبقة الأعمال والواجهات البرمجية. اخترناه لنُضج منظومته في الصلاحيات والطوابير وترحيلات قواعد البيانات — وهي تحديداً ما تحتاجه الأنظمة المؤسسية طويلة العمر.
لغة الخلفية. توفّر بيئات تشغيل واستضافة وكوادر صيانة في كل سوق نعمل فيه، فلا يرتهن النظام بمورّد واحد.
اختيرت بحسب متطلّبات هذا النظام تحديداً، لا بحسب ما هو رائج.
البيانات والأداء Data
قاعدة البيانات المعاملاتية. اخترناها لثبات سلوكها تحت الحِمل ووضوح خطط تنفيذ استعلاماتها، وهو ما يجعل ضبط الأداء عملاً هندسياً لا تخميناً.
تخزين مؤقت للبيانات الأكثر قراءة وإدارة الجلسات. يمتصّ الحِمل عن قاعدة البيانات في الذروة، وهي اللحظة الوحيدة التي يُقاس عليها النظام.
التكامل Integration
واجهات موثّقة تجعل النظام قابلاً للربط بما بعده. هذا ما يحوّل إضافة تطبيق جوال أو نظام ثالث لاحقاً إلى أسابيع بدل مشروع جديد.
إشعار فوري بالأحداث بدل استجواب دوري للطرف الآخر — أخفّ على الطرفين وأقرب إلى اللحظية.
الأنظمة المرتبطة Connected Systems
تحديات هندسية حللناها
القرارات التي اتُّخذت في هذا النظام تحديداً، وسبب كل منها.
طوابير قابلة لإعادة المحاولة
— كل عملية مزامنة تدخل طابوراً. تعطّل أي طرف لساعات لا يعني ضياع طلبات، بل تراكماً يُعالَج تلقائياً عند العودة.
عمليات مُحايدة التكرار
— مفتاح فريد لكل طلب يمنع ازدواج الفواتير مهما تكرّر الاستدعاء. هذا أخطر ما يمكن أن يخطئ فيه نظام فوترة.
مصدر حقيقة واحد للسعر
— حسمنا صراحةً أن المتجر يملك السعر والخصم، والمحاسبة تستقبل لا تحسب.
الأثر بعد التشغيل
ما تغيّر فعلاً في عمل العميل — لا ما وعدنا به قبل البدء.
- أكثر من 1,000 طلب يومياً في الذروة تُعالَج وتُفوتَر آلياً
- إلغاء إعادة الإدخال اليدوي بين المتجر والمحاسبة
- توافق الفواتير مع أسعار الطلبات الفعلية بما فيها الخصومات
- التزام مستمر بمتطلبات الفوترة الإلكترونية دون خطوات يدوية قابلة للنسيان
الأرقام أعلاه تخصّ حجم نظام العميل الذي بنيناه ونشغّل بنيته، لا حجم أعمالنا نحن. ونلتزم باتفاقيات السرية، فنعرض العمق التقني دون أسماء العملاء.