Ezhal: ثلاثة تطبيقات حسب الدور من قاعدة كود واحدة

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

وبناء ثلاثة تطبيقات يعني ثلاث قواعد كود، وثلاث دورات إصدار، وثلاثة أماكن يعيش فيها الخلل نفسه.

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

قاعدة كود واحدة بـ Flutter، فيها طبقة مجال مشتركة وثلاث واجهات حسب الدور فوقها. قواعد الحجز والمحفظة ومسار الدفع تُكتب مرة واحدة؛ وما يتغير حسب الدور هو الشاشات الموجودة وما يُسمح لكل دور بفعله.

وتُدار الحالة بـ Riverpod، وهو ما يبقي المنطق المشترك قابلًا للاختبار ويمنع الواجهات الثلاث من الانحراف إلى ثلاثة تطبيقات تختلف اختلافًا خفيًا في القاعدة نفسها.

وفوق النواة طبقة ولاء يبيع عليها النشاط فعلًا: اشتراكات، ومحفظة، ونقاط، وأختام، وبطاقات Apple Wallet، فيحتفظ العميل ببطاقة خدمته على شاشة القفل.

سُلِّمت Ezhal للعميل كمنتج خاص؛ وهي غير منشورة على متجر عام، فلا يوجد رابط لتثبيتها. ولقطة الشاشة في هذه الصفحة من المنصة نفسها.