التعليم
نظام إدارة تعلّم بحجم جامعي — من O(n×m) إلى O(1)
احتاجت جامعة إلى نظام إدارة تعلّم يعكس بنيتها الحقيقية — جامعات وكليات ومقررات — ويحتفظ بمحاضرات فيديو كبيرة الحجم من دون أن يخسر الرفع عند انقطاع الاتصال، ويتتبّع تقدّم الطالب عبر عدّة معايير إتمام في آنٍ واحد، ويُخضع كل مقرر لخطوة اعتماد قبل أن يصل إلى أي طالب.
التحدي
بنية مؤسسية، وفيديو كبير، وشريط تقدّم يجب أن يكون صحيحاً
كتالوج الجامعة ليس قائمة مقررات مسطّحة — بل جامعات تحتوي كليات تحتوي مقررات، وعلى كل جزء من المنصّة (التسجيل، الصلاحيات، التقارير) أن يحترم هذا الشكل بدل أن يقاومه.
فوق هذه البنية جلست مشكلتان أصعب: محاضرات فيديو كبيرة بما يكفي لأن يفقد انقطاع اتصال واحد ساعة من تقدّم الرفع، ورقم تقدّم لكل طالب كان يجب أن يعكس عدّة معايير إتمام مختلفة — فيديو شوهد، اختبار نُجح فيه، واجب سُلّم — من دون أن يتحوّل كل تحميل للوحة التحكم إلى استعلام يفحص كل طالب مقابل كل عنصر محتوى. وقبل أن يصل أي من ذلك إلى طالب، كان على المقرر أن يجتاز سير عمل اعتماد لا تُشغّله إلا أدوار معيّنة.
ما بنيناه
بنية في المخطّط، رفع يصمد، وتقدّم مُحسَب مسبقاً
بنية جامعة ← كلية ← مقرر مُمثَّلة مباشرة كعلاقات ForeignKey، فتتبع الصلاحيات والاستعلامات شكل المؤسسة الحقيقي بدل تقريب له. رفع الفيديو يمر عبر django-tus وdrf-chunked-upload، اللذين يتتبعان جلسة الرفع ويسمحان لملف كبير بالاستئناف من حيث انقطع الاتصال بدل البدء من جديد.
التقدّم لا يُحسَب عند القراءة. حقول تقدّم مُبسَّطة (denormalized) تُحدَّث عبر إشارات Django عند إتمام الطالب شيئاً، مع مهمة Celery في الخلفية تعيد الحساب دفعياً كلّما تغيّر المحتوى الأساسي — فتقرأ لوحة التحكم رقماً واحداً محسوباً مسبقاً بدل ربط كل سجلات الإتمام. سير عمل مبني على الحالة مع بوابات اعتماد إدارية، مدعوماً بفئات صلاحيات RBAC مخصّصة، يبقي من يملك النشر أو التعديل أو الاعتماد مرتبطاً بدوره الفعلي.
بنية متعددة المستويات
جامعات وكليات ومقررات كعلاقات ForeignKey حقيقية، تطابق تنظيم المؤسسة الفعلي.
رفع فيديو قابل للاستئناف
django-tus وdrf-chunked-upload يتتبعان جلسة الرفع، فتصمد محاضرة الفيديو الكبيرة أمام انقطاع الاتصال.
تقدّم مُبسَّط (denormalized)
حقول تقدّم تُحدَّث بإشارات Django عند إتمام العمل، مع إعادة حساب دفعية عبر Celery عند تغيّر المحتوى.
سير عمل لاعتماد المقررات
سير عمل مبني على الحالة مع بوابات اعتماد إدارية قبل أن يصل المقرر إلى الطالب.
صلاحيات RBAC مخصّصة
فئات صلاحيات مرتبطة بأدوار مؤسسية، لا بتقسيم مسطّح واحد بين إداري وطالب.
الدفع والكوبونات
دفع المقررات متكامل مع نظام كوبونات، خلف جلسات موثَّقة بـJWT.
من الداخل
Django وCelery وS3 يؤدّون العمل بحجم جامعي
- Django 5.0+
- Django REST Framework
- PostgreSQL
- SimpleJWT
- Celery 5.3+
- Redis
- django-tus
- drf-chunked-upload
- AWS S3
- فئات صلاحيات مخصّصة
- إشارات Django
يحمل Celery وRedis العمل الذي لا ينبغي أن يعطّل الطلب — إعادة حساب التقدّم الدفعي، والعمليات الثقيلة في الخلفية — بينما يبقي PostgreSQL والحقول المُبسَّطة مسار القراءة الشائع استعلاماً واحداً.
النتيجة
بحجم جامعي، قابل للاستئناف، وO(1) عند القراءة
تشغّل الجامعة الآن نظام إدارة تعلّم يعكس بنيتها الخاصة بدل إجبار المقررات على قائمة مسطّحة، ويصمد أمام انقطاع الاتصال في رفع الفيديو الكبير، ويعرض لكل طالب رقم تقدّم محسوباً مسبقاً بدل إعادة حسابه عند كل تحميل صفحة.
O(n×m) ← O(1)
استعلامات التقدّم، عبر التبسيط والإشارات
قابل للاستئناف
رفع فيديو مجزّأ يصمد أمام انقطاع الاتصال
في الخلفية
مهام Celery تتولّى إعادة الحساب الدفعية والعمليات الثقيلة
تحتاج منصّة تعكس هيكلك التنظيمي الحقيقي؟
حين تقاوم الصلاحيات والتقارير الهيكلَ التنظيمي بدل أن تطابقه، تفقد لوحات التحكم ثقة مستخدميها. نُمذجن الشكل الحقيقي أولاً.