تخطَّ إلى المحتوى
منتج لعميل

إيمار

تطبيق طالب على الهاتف ولوحة تشغيل على الويب يجب ألا يكونا المنتج نفسه — ونموذج صلاحيات واحد يحرس الحدّ بينهما.

لوحة إيمار بزاوية، ويظهر فيها شريط التنقّل العربي الجانبي ولوحة ترحيب الطالب.

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

الدور
تخطيط المنتج · مهندس برمجيات متكامل
السنة
2025—2026
الحالة
مُسلَّم · منصة خاصة
التصنيف
منتج

إيمار منظومة تعليم إلكتروني ثنائية اللغة: تطبيق Flutter للطلاب، ولوحة ويب منفصلة للإداريين والمعلّمين وطاقم المعلّمين المخوّل. خطّطتُ المنتج، وحدّدتُ الأدوار والصلاحيات وقواعد الجلسات، وبنيتُ اللوحة فوق واجهة .NET أحادية معيارية.

المشكلة

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

النتيجة

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

التقنيات

  • ASP.NET Core 8
  • C#
  • Entity Framework Core
  • PostgreSQL
  • Clean Architecture
  • JWT
  • RBAC
  • Flutter
  • React
  • TypeScript
  • REST API
  • Docker

منتجان، نظام واحد

القرار الحاسم في إيمار اتُّخذ قبل تصميم أي واجهة: للطلاب تطبيقهم الخاص، ولوحة الويب لن تكون لهم أبداً.

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

الأدوار والصلاحيات

إيمار منصة متعدّدة المعلّمين. المعلّم يملك محتواه وطلابه؛ وطاقم المعلّم يعمل نيابةً عنه ضمن حدود؛ والإداريون يشغّلون المنصة عبر الجميع. الخطأ في هذه الهرمية يكشف محتوى معلّم — أو إيراداته — لمعلّم آخر.

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

واجهتان، مسألتان تصميميتان

  • تطبيق الطالب

    بُني بـFlutter وصُمّم حول سؤال واحد: ما الذي أدرسه تالياً؟ المحتوى والواجبات والتقييمات على بُعد أقل عدد ممكن من اللمسات، ويجب أن يبقى التطبيق صالحاً على اتصال متقطّع.

  • لوحة التشغيل

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

تصوّر للواجهة — تطبيق الطالب. واجهة التعلّم ضيّقة عن قصد؛ وأدوات التشغيل في مكان آخر.

تُعامل العربية والإنجليزية كمادتين متكافئتين لا كلغة أصل وترجمة. صُمّم الاتجاهان ولم يُشتق أحدهما من الآخر: للتنقّل والجداول ومعالجة التواريخ وتدفّق النماذج سلوك RTL مكتوب عمداً، بينما تبقى المعرّفات التقنية من اليسار إلى اليمين داخل الشاشات العربية.

معمارية الخادم

الواجهة الخلفية أحادية معيارية على ASP.NET Core 8 بتدفّق تبعيات أحادي الاتجاه بصرامة. طبقة المجال لا تعرف شيئاً عن التخزين أو HTTP؛ وطبقة التطبيق تحوي الخدمات وكائنات النقل والمدقّقات ومنافذ المزوّدين؛ والبنية التحتية تنفّذها؛ وطبقة الواجهة تركّب فقط. هذا القيد هو ما يمنع منصة بهذا العدد من الوحدات من التحوّل إلى خدمة متشابكة.

  • المجال

    بلا EF ولا حقن تبعيات ولا HTTP

    • Entities
    • Enums
    • Interfaces
  • التطبيق

    خدمات وعقود الأعمال

    • Services
    • DTOs
    • Validators
    • Provider ports
  • البنية التحتية

    التخزين والمحوّلات

    • DbContext
    • Migrations
    • Seeders
    • JWT / OTP / hashing
  • الواجهة

    تركيب فقط

    • Controllers
    • Middleware
    • Swagger
    • Health checks
تدفّق التبعيات: المجال ← التطبيق ← البنية التحتية ← الواجهة. ولا تعود الأسهم للخلف أبداً.
  1. 01

    التفعيل

    يستخدم الطالب كود تفعيل يمنح وصولاً إلى محتوى محدّد لا إلى المنصة عموماً.

  2. 02

    ربط الجهاز

    تُربط الجلسة بجهاز، فلا يمكن مشاركة حساب واحد عبر عدد غير محدود من الهواتف.

  3. 03

    التخويل

    يُفحص كل طلب محتوى مقابل استحقاقات الطالب — لا مقابل كونه مسجّل الدخول فقط.

  4. 04

    التسليم

    يُقدَّم الفيديو والمواد عبر مسار محمي، مع إعادة تقييم الاستحقاق بدل تخزينه بلا نهاية.

تسليم المحتوى المحمي — المسار الذي يسلكه درس مدفوع قبل وصوله إلى جهاز الطالب.

القرارات الهندسية

  • التحدّي

    مشاركة حساب واحد بين صفّ كامل تُسقط النموذج التجاري لمنصة تعليم مدفوعة.

    القرار

    إدارة الأجهزة والجلسات تربط الجلسة النشطة بجهاز، مع أدوات إدارية لإعادة الضبط عند تغيير الطالب هاتفه بشكل مشروع.

    المقايضة

    يضيف مساراً للدعم — لكن البديل منصة لن ينشر عليها المعلّمون.

  • التحدّي

    الصلاحيات المكتوبة كفحوص متناثرة في المتحكّمات تصبح غير قابلة للتدقيق.

    القرار

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

    المقايضة

    يتطلّب انضباطاً في الزرع والترحيل مع كل إصدار.

  • التحدّي

    بيئة عرض بحسابات تبدو حقيقية هي خطر أمني إنتاجي مؤجّل.

    القرار

    حسابات بيئة التطوير مقيّدة بحيث لا يمكن إنشاؤها في بيئة الإنتاج إطلاقاً.

    المقايضة

    إعدادات أكثر قليلاً لكل بيئة، ولا فرصة لوصول كلمة مرور معروفة إلى الإنتاج.

النتيجة

  • الحالة

    مُسلَّم · منصة خاصة

  • الواجهات

    تطبيق طالب بـFlutter + لوحة ويب

  • دوري

    تخطيط المنتج والتنفيذ المتكامل

  • اللغات

    العربية والإنجليزية بتكافؤ كامل

إيمار هو المشروع الذي أقنعني أن معظم عملي هو رسم الحدود. لم تكن الوحدات هي الجزء الصعب — المقرّرات والاختبارات والحضور والمالية كلها قابلة للحل. الصعب كان تحديد ما يُسمح لكل دور برؤيته، والتمسّك بذلك الحدّ بينما تتوسّع قائمة الميزات.

الدراسة التالية

تبني شيئاً في هذا المجال؟

أنا متاح لعدد محدود من المشاريع. أخبرني بما تعمل عليه.