التحدي
الجيم في الحقيقة تلات أعمال لابسين زي واحد. المتدرب عايز تمارين وتغذية متفصّلة عليه. المدير عايز يشوف الحضور والاشتراكات والإيراد بوضوح. والكوتش عايز يبيع باقات ويحافظ على عملائه من غير ما يدير شغله كله من شات.
أغلب برامج اللياقة بتختار واحد من التلاتة وبتعامل الاتنين التانيين كإضافة. وبناء تلات تطبيقات منفصلة بيحل مشكلة المنتج وبيخلق مشكلة صيانة — تلات دورات إصدار، وتلات مسارات تسجيل دخول، وتلات أماكن يستخبى فيها الباج.
الحل
فريقنا بنى تطبيق Flutter واحد بنقطة دخول واحدة بتتفرع حسب الدور، فتجربة المتدرب والمدير والكوتش بيشتركوا في التنقل والثيم وتسجيل الدخول والاتصال بالشبكة بدل ما كل واحدة تعيد بناءهم. ووراهم API بـ .NET 10 على ASP.NET Core مبني بمعمارية نظيفة وCQRS، فمسارات القراءة اللي بتغذي اللوحات فاضلة منفصلة عن مسارات الكتابة اللي بتحرك فلوس.
تحليل الحركة كان هو القيد الحاسم. بثّ الفيديو لسيرفر عشان تصحيح الأداء مكلف، وبيسرّب خصوصية، وبيقع على واي-فاي الجيم — فالشغل ده بيحصل على الجهاز نفسه بـ Google ML Kit، والباك-إند عمره ما بيستلم غير النتايج. SignalR بيوصّل التحديثات اللحظية في الأماكن اللي فعلًا محتاجة تكون لحظية، وRedis بيمتص ضغط القراءة اللي شاشات الحضور والاشتراكات بتولّده.
وجانب التجارة دخل بترتيب مقصود: Paymob للمدفوعات الأول، بعدين تسويات السوق عشان الكوتشات ياخدوا فلوسهم، بعدين تسويات البوابة، وفي الآخر وضع عمولة أوفلاين للجيمات اللي لسه بتقبض كاش على الباب.
النتايج
المنصة بتغطي الدايرة كاملة — المتدرب بيحجز وبيتمرن، والكوتش بيبيع وبيسلّم، والمدير بيتابع الحضور والإيراد، والفلوس بتتحرك صح في كل اتجاه. تمنتاشر دورة تسليم ودّتها من أول مواصفة للمنصة لحد تحليل الحركة بالذكاء الاصطناعي والمدفوعات والتسويات ولوحة الأدمن، وجولة تقوية للإنتاج غطت التوسع وCI/CD والمراقبة.
وعشان التلات أدوار شايلين كود واحد، أي إصلاح في تسجيل الدخول أو الشبكة بيوصل للتلاتة مرة واحدة بدل تلات مرات.
