المشكلة

احتاجت HDTC إلى نظام إدارة تعلّم خاص بها بدل استئجار مقعد على منصة يملكها غيرها: مقررات، وحسابات مصرّح لها بالوصول إليها، داخل قاعدة بيانات تملكها الجهة نفسها. وكان المطلوب محددًا في أمرين: القابلية للتوسع، لأن النظام يجب أن يستمر في العمل مع نمو المحتوى والمستخدمين؛ والمصادقة، لأن التحكم في الوصول يجب أن يكون حقيقيًا لا مجرد نموذج تسجيل دخول أمام ملفات يمكن تخمين روابطها.

دوري في المشروع

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

البنية المعمارية

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

التقنيات

Laravel و PHP و PostgreSQL.

النتيجة

صارت لدى HDTC منصة تعلّم خاصة بها، بإدارة مقررات ومصادقة آمنة، وعلى حزمة تقنية يسهل التوظيف عليها بدل منتج مغلق يصعب الخروج منه. وقد عولج مطلب التوسع بنيويًا لا بالعتاد: نموذج PostgreSQL مُطبَّع وقاعدة كود Laravel معتادة يجعلان النمو مسألة إضافة محتوى وفهارس، لا إعادة كتابة النظام.