مشروع التخرج — Backend Team

خطة تنفيذ FIENDA
Backend

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

14
أسبوع تنفيذ
5
مراحل رئيسية
70
مفهوم تعليمي
3
أعضاء Backend

رحلة الخدمة داخل النظام

كل خدمة بتمر بـ 7 مراحل أساسية من لحظة وصف العميل لاحتياجه لحد تقييم الخدمة بعد تنفيذها.

1

Need

العميل يشرح احتياجه ويوصفه بالتفصيل

2

Understand

النظام يفهم التفاصيل ويستخرج البيانات المهمة

3

Match

النظام يحدد مقدمي الخدمات المناسبين

4

Connect

العميل ومقدم الخدمة يتواصلان عبر المنصة

5

Manage

متابعة حالة الطلب وتنفيذه

6

Complete

تأكيد اكتمال الخدمة

7

Rate

تقييم الخدمة ومقدمها

الأدوار الأساسية

Customer

يبحث عن الخدمات، ينشئ الطلبات، يتواصل مع مقدمي الخدمات ويقيّمهم.

Provider

يدير ملفه الشخصي وخدماته وتوافره ويستقبل الطلبات ويتعامل معها.

Admin

يدير المستخدمين ومقدمي الخدمات والتصنيفات والشكاوى والمراجعات.

أهداف فريق الـ Backend

بنهاية فترة التنفيذ، المفروض الفريق يكون قادر على تحقيق كل الأهداف دي:

بناء RESTful APIs منظمة وقابلة للتوسع
تطبيق Authentication وAuthorization بصورة صحيحة
تصميم قاعدة بيانات مترابطة وفعّالة
إدارة دورة حياة طلب الخدمة من الإنشاء حتى الإكمال
تنفيذ البحث والتصفية وترشيح مقدمي الخدمات
دمج الذكاء الاصطناعي مع النظام
تنفيذ المحادثات والإشعارات
اختبار النظام ونشره للعرض النهائي

التقنيات المقترحة

الأدوات والتقنيات اللي هنشتغل بيها في المشروع — اضغط على أي تقنية لفتح شرحها.

C#
لغة البرمجة الأساسية
ASP.NET Core Web API
الإطار الأساسي
Clean Architecture
هيكلة المشروع
Modular Monolith
أسلوب التطبيق
Entity Framework Core
ORM للتعامل مع قاعدة البيانات
Identity + JWT
المصادقة والتوثيق
SignalR
الاتصال اللحظي
Swagger / OpenAPI
توثيق الـ APIs
xUnit
اختبارات الكود
Git & GitHub
إدارة الكود والتعاون
Docker
النشر والحاويات
SQL Server / PostgreSQL
قاعدة البيانات

  هيكل الـ Solution المقترح

FIENDA.Domain
الكيانات وقواعد العمل الأساسية
FIENDA.Application
حالات الاستخدام، الخدمات، DTOs، والـ Interfaces
FIENDA.Infrastructure
قاعدة البيانات وEF Core والخدمات الخارجية
FIENDA.API
Controllers وMiddleware وإعدادات الـ API
FIENDA.Tests
الاختبارات

الجدول الزمني — 12 إلى 14 أسبوع

بافتراض تخصيص نحو 10–15 ساعة أسبوعيًا لكل عضو.

المرحلة 1تأسيس المهاراتالأسبوع 1–2
C# Fundamentals
  • Value Types وReference Types
  • Classes وObjects
  • Encapsulation وInheritance وPolymorphism
  • Interfaces وAbstract Classes
  • Collections وGenerics
  • Exception Handling
  • LINQ
  • Async/Await وTask
Web Fundamentals
  • HTTP Methods: GET, POST, PUT, PATCH, DELETE
  • HTTP Status Codes
  • REST API وJSON
  • Dependency Injection
  • Controllers وRouting
  • DTOs وModel Validation
  • الفرق بين Authentication وAuthorization
SQL Fundamentals
  • Tables وRelationships
  • Primary Keys وForeign Keys
  • SELECT وINSERT وUPDATE وDELETE
  • JOINs
  • Constraints وIndexes
Git & GitHub
  • Repository وBranches
  • Commits وPull Requests
  • Merge Conflicts
  • مراجعة الكود قبل الدمج
المطلوب بنهاية المرحلة

تنفيذ مشروع تدريبي صغير باستخدام ASP.NET Core Web API، يدعم CRUD لبيانات بسيطة، ويتصل بقاعدة بيانات ويحتوي على Validation وSwagger.

المرحلة 2بناء أساس المشروعالأسبوع 3–5
الأسبوع 3: Architecture
  • إنشاء الـ Solution بالمشروعات المنفصلة
  • تحديد مسؤوليات كل Layer
  • تطبيق Dependency Injection
  • فهم الفرق بين Entity وDTO وService وRepository
  • الاتفاق على أسلوب موحّد لتنظيم الكود
الأسبوع 4: Database Design
  • User, ProviderProfile, Category, Service
  • Address, ServiceRequest, Message
  • Review, Notification
  • MenuItem, Order, OrderItem (سيناريو الطعام)
  • تحديد العلاقات والقيود المطلوبة
  • مراعاة صحة البيانات التاريخية
الأسبوع 5: EF Core & API Foundation
  • إنشاء DbContext وEntity Configurations
  • تنفيذ Migrations
  • إعداد الاتصال بقاعدة البيانات
  • بناء CRUD APIs الأساسية
  • إنشاء Global Exception Handling
  • إعداد Logging
  • توحيد Validation وAPI Responses
  • توثيق الـ APIs باستخدام Swagger
المطلوب بنهاية المرحلة

هيكل Backend واضح، واتصال سليم بقاعدة البيانات، وأول مجموعة APIs تعمل ويمكن اختبارها.

المرحلة 3تنفيذ الوظائف الأساسيةالأسبوع 6–9
الأسبوع 6: Authentication & Authorization
  • تسجيل المستخدمين وتسجيل الدخول
  • إدارة كلمات المرور بطريقة آمنة
  • إنشاء JWT والتحقق منه
  • تطبيق Roles: Customer وProvider وAdmin
  • حماية الـ Endpoints
  • التأكد من ملكية الموارد وليس Role فقط
الأسبوع 7: Users & Providers
  • إدارة الملف الشخصي
  • إنشاء وتحديث ملف مقدم الخدمة
  • إدارة بيانات الخدمات المقدمة
  • إدارة التوافر
  • التحقق الإداري من مقدمي الخدمات
  • تفعيل وإيقاف الحسابات
الأسبوع 8: Categories, Services & Search
  • إدارة التصنيفات والخدمات
  • البحث عن الخدمات ومقدميها
  • التصفية حسب الموقع والتصنيف والسعر والتوافر
  • Pagination وSorting
  • تحسين استعلامات قاعدة البيانات
الأسبوع 9: Service Request Lifecycle

تنفيذ دورة حياة الطلب بقواعد واضحة — تحديد الحالات والانتقالات المسموحة وصلاحيات كل انتقال.

Pending
←
Accepted
←
InProgress
←
Completed
Rejected
أو
Cancelled
المطلوب بنهاية المرحلة

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

المرحلة 4التكاملات والوظائف المتقدمةالأسبوع 10–11
Matching System
  • استقبال متطلبات العميل
  • البحث داخل بيانات مقدمي الخدمات الفعلية
  • ترتيب النتائج حسب نوع الخدمة والموقع والتوافر
  • إرجاع أسباب واضحة لاختيار النتائج
AI Integration
  • إرسال وصف احتياج العميل لنموذج AI
  • استخراج بيانات منظمة: نوع الخدمة، الموقع، الوقت، الميزانية
  • التحقق من صحة المخرجات قبل استخدامها
  • عدم السماح للـ AI بإنشاء بيانات غير موجودة
  • التعامل مع فشل النموذج أو بطء الاستجابة
Real-Time Chat — SignalR
  • إنشاء المحادثات وربطها بالطلبات
  • حفظ الرسائل في قاعدة البيانات
  • التحقق من صلاحية الوصول للمحادثة
  • إرسال واستقبال رسائل لحظية
  • عدم الاعتماد على الاتصال اللحظي وحده في الحفظ
Notifications & Reviews
  • إشعارات إنشاء الطلب وقبوله وتغيير حالته
  • إشعارات الرسائل
  • التقييم بعد اكتمال الخدمة فقط
  • منع تكرار التقييم لنفس الطلب
Admin APIs
  • إدارة المستخدمين ومقدمي الخدمات
  • إدارة التصنيفات
  • مراجعة البلاغات والمحتوى المخالف
  • عرض بيانات إدارية أساسية
المطلوب بنهاية المرحلة

تكامل الوظائف الأساسية مع المطابقة والمحادثات والإشعارات، وتجهيز سيناريو متكامل قابل للتجربة.

المرحلة 5الاختبارات والنشرالأسبوع 12–14
Testing
  • Unit Tests لمنطق العمل
  • Integration Tests للـ APIs وقاعدة البيانات
  • اختبار Authentication وAuthorization
  • اختبار انتقالات حالات الطلب
  • اختبار البيانات الناقصة والحالات غير الصحيحة
  • اختبار السيناريوهات من البداية للنهاية
Security & Reliability
  • تخزين الأسرار في Configuration آمن
  • عدم رفع كلمات المرور أو المفاتيح لـ GitHub
  • استخدام HTTPS في بيئة النشر
  • التحقق من المدخلات والصلاحيات
  • عدم تسجيل بيانات حساسة في Logs
  • إخفاء التفاصيل الداخلية عن المستخدم
Deployment
  • إعداد Docker
  • إعداد CI/CD باستخدام GitHub Actions
  • تجهيز إعدادات Development وProduction
  • تحديد طريقة تشغيل Migrations في النشر
  • نشر الـ API وربطها بالتطبيق
  • اختبار قواعد العمل بعد النشر
المطلوب بنهاية المرحلة

اختبار الرحلة الكاملة للمستخدم ومقدم الخدمة والتأكد من أن الوظائف المطلوبة للعرض النهائي تعمل بدون تدخل يدوي غير ضروري.

تقسيم المسؤوليات

التقسيم مبدئي وممكن يتغير حسب مستوى كل عضو. الـ Architecture وقواعد العمل المشتركة مسؤولية الفريق كله.

D1
LEAD
Developer 1 — Backend Lead
  • تصميم Architecture وهيكل الـ Solution
  • وضع قواعد التسمية والـ Conventions
  • قيادة تصميم الـ Domain وDatabase Design
  • تحديد العقود بين الـ Modules
  • مراجعة Pull Requests
  • حل مشاكل الدمج والتكامل
  • متابعة المهام والمخاطر الفنية
  • المشاركة في Auth وMatching
D2
DATA & PROVIDER
Developer 2 — Data Module
  • تصميم وتنفيذ كيانات قاعدة البيانات
  • Entity Configurations وEF Core
  • Migrations بالتنسيق مع الفريق
  • APIs التصنيفات والخدمات ومقدمي الخدمات
  • البحث والتصفية وPagination
  • مراجعة الاستعلامات والعلاقات
D3
BUSINESS FEATURES
Developer 3 — Features Module
  • Service Requests وDTOs وValidation
  • تنفيذ قواعد دورة حياة الطلب
  • Reviews وNotifications
  • كتابة Tests للوظائف المسؤولة عنها
  • دعم التكامل بين المحادثات والطلبات

ترتيب أولويات التنفيذ

ركزوا على P0 أولًا، بعدين P1 بعد استقرار الأساس، وP2 حسب الوقت المتاح.

P0 — أساسي لا بد منه

الوظائف الأساسية

  • Authentication & Authorization
  • Users & Provider Profiles
  • Categories & Services
  • Service Requests
  • Database Design
  • Validation وError Handling
P1 — مهم بعد استقرار الأساس

وظائف مهمة

  • Search & Matching
  • AI Integration
  • Reviews
  • Notifications
  • SignalR Chat
  • Admin APIs
P2 — إضافي حسب الوقت

وظائف إضافية

  • Food Orders
  • Menu وCart وCheckout
  • تحسينات متقدمة للبحث
  • تحليلات وتقارير إضافية
  • خصائص غير ضرورية للسيناريو الأساسي
ملاحظة: إذا كان سيناريو طلب الطعام مطلوب في العرض النهائي، يجب تقديم وحدات الطعام في الأولوية بدلًا من تأجيلها.

قواعد العمل الجماعي على GitHub

1
استخدام Branch منفصل لكل Feature أو مهمة واضحة.
2
عدم تنفيذ العمل مباشرةً على main.
3
فتح Pull Request قبل الدمج.
4
إجراء Code Review قبل الموافقة على الدمج.
5
تشغيل Build والاختبارات قبل الدمج.
6
عدم تعديل Database Schema منفردًا دون تنسيق مع الفريق.
7
توثيق أي تغيير يؤثر على أكثر من Module.
8
حل تعارضات الدمج ومراجعة الـ Migrations بعناية.
9
الاحتفاظ بمهام واضحة على لوحة المشروع مع تحديد المسؤول والحالة.

أمثلة أسماء الفروع

feature/authenticationfeature/provider-services feature/service-requestsfeature/matching bugfix/request-status-validation

معايير اكتمال أي Feature

لا تعتبر أي Feature مكتملة لمجرد أن الـ Endpoint يعمل. تأكد من كل النقط دي:

المتطلبات وقواعد العمل واضحة
الـ DTOs والـ Validation موجودة
الصلاحيات وملكية الموارد مطبقة
الحالات الاستثنائية يتم التعامل معها
تغييرات DB موثقة عبر Migrations
الـ API موثقة ويمكن تجربتها من Swagger
الاختبارات المناسبة مكتوبة وناجحة
لا توجد أسرار أو بيانات حساسة في الكود
الكود تمت مراجعته ودمجه بعد الموافقة

أول أسبوعين — ابدأوا من هنا

الأفضل ألا يبدأ كل عضو ببناء Module منفصل من أول يوم. اتعلموا الأساسيات ونفذوا مشروع تدريبي مشترك الأول.

الأسبوع الأول — التعلم
  • مراجعة أساسيات C# وOOP
  • فهم Interfaces وDependency Injection
  • دراسة أساسيات HTTP وREST APIs
  • مراجعة SQL وRelationships وJOINs
  • تعلم أساسيات Git وGitHub
الأسبوع الثاني — التطبيق
  • إنشاء ASP.NET Core Web API
  • تنفيذ CRUD باستخدام EF Core
  • استخدام DTOs وValidation
  • إضافة Swagger وException Handling
  • العمل بـ Branches وPull Requests
  • إجراء Code Review بين الأعضاء
النتيجة المتوقعة

يكون كل عضو قادرًا على فهم الكود المشترك، إضافة Endpoint بسيط، والتعامل مع قاعدة البيانات، ورفع التعديل إلى GitHub بطريقة صحيحة.

نصائح مهمة للـ Backend Lead

لا تبدأوا بـ Microservices — ابدأوا بـ Modular Monolith ما دام حجم الـ MVP يسمح.
لا تبالغوا في التصميم قبل وضوح المتطلبات الفعلية.
اتفقوا على Database Schema والعلاقات مبكرًا.
لا تجعلوا الـ Controller يحتوي على منطق العمل الأساسي.
افصلوا بين بيانات الـ API الداخلية والـ DTOs اللي بتوصل للمستخدم.
لا تعتمدوا على الواجهة الأمامية في تطبيق الصلاحيات أو التحقق.
لا تدمجوا جميع الوظائف قبل اختبار كل Module منفردًا.
سيناريو قابل للعمل أهم من عدد كبير من الـ Endpoints غير المكتملة.
خصصوا وقت مستمر للتكامل والاختبار — مش في آخر أسبوع بس.

  النتيجة النهائية المستهدفة

Backend منظم وقابل للاختبار والنشر، يدعم تسجيل المستخدمين، وإدارة مقدمي الخدمات، والبحث والمطابقة، وإنشاء الطلبات ومتابعتها، والمحادثات والإشعارات والتقييمات.

الأهم أن يكون كل جزء مبني على قواعد عمل واضحة ومتكامل مع باقي أجزاء المنصة، بحيث يستطيع فريق Flutter استهلاك الـ APIs، ويستطيع فريق AI تقديم مخرجات منظمة للنظام.