404 Not Found

404 Not Found


nginx

تمرين عملي شامل: تصميم مشروع OrderFlow

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

1. ما ستتعلمه


2. قصة حقيقية لمدير منتج

(1) نقطة الألم: الفجوة بين المتطلبات والكود

جاء Charlie إلى Alice بمستند متطلبات غامض: "نحتاج نظام إدارة طلبات تجارة إلكترونية." سألت Alice: "ما الميزات المطلوبة؟ ما أدوار المستخدمين المختلفة؟ ما سمات المنتجات؟ كيف ترتبط الطلبات والمدفوعات؟" لم يستطع Charlie الشرح بوضوح، فاضطرت Alice للتخمين بناءً على خبرتها. نتيجة لذلك، بعد أسبوعين من التطوير، قال Charlie: "هذا ليس ما أردته."

(2) حلول تصميم المنظومة

صمم أولاً، ثم طوّر—تحليل المتطلبات ← اختيار التقنيات ← تصميم قاعدة البيانات ← مواصفات واجهة برمجة التطبيقات. أكد كل خطوة مع Charlie:

100%
graph TD
    A["تحليل<br/>المتطلبات"] --> B["اختيار<br/>التقنيات"]
    B --> C["تصميم<br/>قاعدة البيانات"]
    C --> D["مواصفات<br/>واجهة برمجة التطبيقات"]
    D --> E["خطة<br/>التطوير"]

(3) الإيرادات

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


3. تحليل المتطلبات

(1) أربعة وحدات رئيسية

الوحدة الميزات الأساسية أدوار المستخدمين
إدارة المستخدمين التسجيل، تسجيل الدخول، المعلومات الشخصية، إدارة الأدوار الجميع
إدارة المنتجات CRUD، الفئات، البحث، إدارة المخزون ADMIN
إدارة الطلبات تقديم الطلبات، عرض الطلبات، إلغاء الطلبات، الإلغاء التلقائي بسبب انتهاء المهلة CUSTOMER / ADMIN
إدارة المدفوعات بدء المدفوعات، معالجة رد الاتصال، الاسترداد CUSTOMER / ADMIN

(2) مصفوفة الأدوار والصلاحيات

الميزة CUSTOMER ADMIN
التسجيل / تسجيل الدخول
تصفح المنتجات
البحث عن المنتجات
إنشاء / إدارة المنتجات
تقديم طلب
عرض طلباتك
عرض جميع الطلبات
إلغاء طلبك
إلغاء أي طلب
بدء الدفع
معالجة الاسترداد

(1) ▶ مثال: قصة المستخدم

TEXT
بصفتي CUSTOMER، أريد:
  - تصفح والبحث عن المنتجات
  - إضافة منتجات إلى سلة التسوق (مستقبلاً)
  - تقديم طلب بعناصر متعددة
  - عرض سجل طلباتي
  - إلغاء طلب غير مدفوع خلال 30 دقيقة
  - الدفع مقابل طلب
  - عرض حالة الدفع

بصفتي ADMIN، أريد:
  - إدارة المنتجات (CRUD)
  - عرض جميع الطلبات
  - إلغاء أي طلب
  - معالجة الاستردادات
  - عرض إحصائيات الأعمال

الناتج:

TEXT
التنفيذ ناجح

4. اختيار التقنيات

(1) مصفوفة قرار اختيار المنتج

نقطة القرار الخيار أ الخيار ب الاختيار السبب
أطر الويب WebMVC WebFlux WebMVC في الأساس CRUD، تزامن < 5,000؛ WebMVC أبسط
طريقة المصادقة Session JWT JWT بنية خدمات مصغرة، نشر متعدد المثيلات، مصادقة عديمة الحالة
استراتيجية التخزين المؤقت Caffeine محلي Redis موزع L1 Caffeine + L2 Redis وصول محلي سريع للبيانات الساخنة؛ التخزين المؤقت الموزع يضمن الاتساق
قاعدة البيانات PostgreSQL MySQL MySQL مألوف للفريق، نظام بيئي ناضج
الوصول إلى قاعدة البيانات JPA MyBatis JPA تعيين كائنات أكثر طبيعية، يقلل الحاجة لكتابة SQL
توثيق واجهة برمجة التطبيقات SpringDoc يدوي SpringDoc توليد توثيق OpenAPI تلقائيًا

(2) نظرة عامة على حزمة التقنيات

الطبقة التقنية الإصدار
اللغة Java 17 LTS
الإطار Spring Boot 3.2.x
الويب Spring MVC 6.x
الأمان Spring Security + JWT 6.x
قاعدة البيانات MySQL 8.0
ORM Spring Data JPA 3.x
التخزين المؤقت Caffeine + Redis 3.x / 7.x
التحقق Bean Validation 3.x
الاختبار JUnit 5 + Mockito + TestContainers 5.x
التوثيق SpringDoc OpenAPI 2.x
المراقبة Actuator + Micrometer 3.x
النشر Docker + Kubernetes 24.x / 1.28

5. تصميم قاعدة البيانات

(1) مخطط ER الكامل

100%
erDiagram
    USER ||--o{ ORDER : "يقدم"
    PRODUCT ||--o{ ORDER_ITEM : "مضمن في"
    ORDER ||--o{ ORDER_ITEM : "يحتوي على"
    ORDER ||--o| PAYMENT : "يمتلك"

    USER {
        bigint id PK
        varchar username UK
        varchar email UK
        varchar password_hash
        varchar role
        timestamp created_at
        timestamp updated_at
    }
    PRODUCT {
        bigint id PK
        varchar name
        varchar sku UK
        decimal price
        int stock
        varchar category
        tinyint status
        timestamp created_at
        timestamp updated_at
    }
    ORDER {
        bigint id PK
        bigint user_id FK
        varchar order_number UK
        varchar status
        decimal total_amount
        timestamp created_at
        timestamp updated_at
    }
    ORDER_ITEM {
        bigint id PK
        bigint order_id FK
        bigint product_id FK
        int quantity
        decimal unit_price
        decimal subtotal
    }
    PAYMENT {
        bigint id PK
        bigint order_id FK
        varchar transaction_id UK
        varchar method
        varchar status
        decimal amount
        timestamp paid_at
        timestamp created_at
    }

(1) ▶ مثال: عبارة DDL لإنشاء الجداول

SQL
CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    role VARCHAR(20) NOT NULL DEFAULT 'CUSTOMER',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE products (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    sku VARCHAR(20) NOT NULL UNIQUE,
    price DECIMAL(10,2) NOT NULL,
    stock INT NOT NULL DEFAULT 0,
    category VARCHAR(50),
    status TINYINT NOT NULL DEFAULT 1,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_product_name (name),
    INDEX idx_product_category (category)
);

CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    order_number VARCHAR(20) NOT NULL UNIQUE,
    status VARCHAR(20) NOT NULL DEFAULT 'PENDING',
    total_amount DECIMAL(10,2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_order_user (user_id),
    INDEX idx_order_status_created (status, created_at DESC),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

CREATE TABLE order_items (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INT NOT NULL,
    unit_price DECIMAL(10,2) NOT NULL,
    subtotal DECIMAL(10,2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

CREATE TABLE payments (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    order_id BIGINT NOT NULL UNIQUE,
    transaction_id VARCHAR(50) UNIQUE,
    method VARCHAR(20) NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'PENDING',
    amount DECIMAL(10,2) NOT NULL,
    paid_at TIMESTAMP NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (order_id) REFERENCES orders(id)
);

الناتج:

TEXT
CREATE TABLE

6. تصميم مواصفات واجهة برمجة التطبيقات

(1) مواصفات واجهة برمجة التطبيقات RESTful

(1) ▶ مثال: قائمة نقاط نهاية واجهة برمجة التطبيقات

الوحدة الطريقة URI الوصف الصلاحيات
المصادقة POST /api/v1/auth/login تسجيل الدخول عام
المصادقة POST /api/v1/auth/register التسجيل عام
المنتجات GET /api/v1/products قائمة المنتجات عام
المنتجات GET /api/v1/products/{id} تفاصيل المنتج عام
المنتجات POST /api/v1/products إنشاء منتج ADMIN
المنتجات PUT /api/v1/products/{id} تحديث منتج ADMIN
المنتجات DELETE /api/v1/products/{id} حذف منتج ADMIN
الطلبات POST /api/v1/orders تقديم طلب CUSTOMER+
الطلبات GET /api/v1/orders طلباتي CUSTOMER+
الطلبات GET /api/v1/orders/{id} تفاصيل الطلب المالك/ADMIN
الطلبات GET /api/v1/admin/orders جميع الطلبات ADMIN
الطلبات DELETE /api/v1/orders/{id} إلغاء الطلب المالك/ADMIN
المدفوعات POST /api/v1/payments بدء الدفع CUSTOMER+
المدفوعات POST /api/v1/payments/callback رد اتصال الدفع داخلي

(2) ▶ مثال: تنسيق الاستجابة المعياري

JAVA
// استجابة ناجحة
public record ApiResponse<T>(
    int code,
    String message,
    T data,
    Instant timestamp
) {
    public static <T> ApiResponse<T> success(T data) {
        return new ApiResponse<>(200, "OK", data, Instant.now());
    }
    public static <T> ApiResponse<T> created(T data) {
        return new ApiResponse<>(201, "Created", data, Instant.now());
    }
}

// استجابة مرقمة
public record PagedResponse<T>(
    List<T> content,
    int page,
    int size,
    long totalElements,
    int totalPages
) {}

الناتج:

TEXT
// التنفيذ ناجح

(3) ▶ مثال: معاملات الترقيم والفرز

BASH
# قائمة المنتجات مع الترقيم والفرز والتصفية
GET /api/v1/products?page=0&size=20&sort=price,desc&category=electronics&minPrice=100&maxPrice=999

الناتج:

TEXT
# تم تنفيذ الأمر بنجاح

7. خطة التطوير وتعيينات الوحدات

(1) ▶ مثال: خطة التكرار

Sprint التكرار الهدف المخرجات
Sprint 1 الأسابيع 1-2 الإطار الأساسي هيكل المشروع + المصادقة + CRUD المنتجات
Sprint 2 الأسابيع 3-4 الأعمال الأساسية وحدة الطلبات + المعاملات + التحقق + الاستثناءات
Sprint 3 الأسابيع 5-6 الميزات المتقدمة التخزين المؤقت + المهام المجدولة + الإشعارات غير المتزامنة
Sprint 4 الأسابيع 7-8 العمليات والنشر Docker + K8s + المراقبة والتنبيهات

8. مثال شامل: مستند تصميم مشروع OrderFlow

MARKDOWN
# مستند تصميم منظومة OrderFlow

## 1. المتطلبات التجارية
- نظام إدارة طلبات التجارة الإلكترونية
- 4 وحدات: المستخدمون، المنتجات، الطلبات، المدفوعات
- دوران: CUSTOMER، ADMIN
- المتوقع: 10,000 DAU، 1,000 طلب/يوم

## 2. حزمة التقنيات
- Java 17 + Spring Boot 3.2.x
- MySQL 8.0 + Spring Data JPA
- Redis 7 + Caffeine (تخزين مؤقت ثنائي المستوى)
- Spring Security + JWT (خادم موارد OAuth2)
- نشر Docker + Kubernetes

## 3. تصميم قاعدة البيانات
- 5 جداول: users، products، orders، order_items، payments
- فهارس على أعمدة الاستعلام عالية التردد

## 4. مواصفات واجهة برمجة التطبيقات
- واجهة برمجة تطبيقات RESTful مع إصدارات (/api/v1/)
- مصادقة JWT Bearer
- تنسيق استجابة موحد: ApiResponse<T>
- الترقيم: معاملات page، size، sort

## 5. المتطلبات غير الوظيفية
- زمن استجابة P99 < 100 مللي ثانية
- معدل الخطأ < 0.1%
- التوفر > 99.9%
- تغطية الاختبار الآلي > 80%

❓ أسئلة شائعة

س لماذا اختيار WebMVC بدلاً من WebFlux؟
ج OrderFlow يتضمن في الأساس عمليات CRUD، مع تزامن متوقع < 5,000 QPS؛ WebMVC أبسط وأكثر نضجًا. WebFlux مناسب لسيناريوهات الإدخال/الإخراج المكثف والتزامن العالي والتدفق في الوقت الفعلي؛ استخدامه لمشروع CRUD سيزيد التعقيد فعليًا.
س لماذا استخدام تخزين مؤقت ثنائي المستوى بدلاً من Redis فقط؟
ج L1 Caffeine هو الأسرع (مستوى النانوثانية)، بينما L2 Redis يضمن الاتساق عبر مثيلات متعددة. البيانات الساخنة تصيب ذاكرة التخزين المؤقت المحلية، مما يقلل عبء شبكة Redis.
س هل يجب أن يستخدم إصدار واجهة برمجة التطبيقات مسارات URL أم رؤوس؟
ج إصدار مسار URL (/api/v1/) أكثر بديهية وأسهل في الاختبار وأكثر ملاءمة لـ SEO. إصدار الرأس أكثر توافقًا مع REST لكن أصعب في التصحيح. عمليًا، نوصي بإصدار URL.
س كيف يتم تأمين أمان ردود اتصال الدفع؟
ج 1) URL رد الاتصال متاح فقط من الشبكة الداخلية؛ 2) يتم التحقق من توقيع رد الاتصال؛ 3) المعالجة الترابطية (ردود الاتصال المتكررة لا تؤدي إلى رسوم مكررة)؛ 4) تسجيل أحداث رد الاتصال لأغراض التسوية.
س كيف يجب التعامل مع الحذف الناعم والحذف الصلب في تصميم قاعدة البيانات؟
ج استخدم الحذف الناعم (status=CANCELLED) لبيانات الأعمال الحرجة (الطلبات، المدفوعات) للحفاظ على مسارات التدقيق. البيانات المساعدة (منتجات الاختبار) يمكن حذفها بشكل صلب. الحذف الناعم يتطلب تصفية السجلات المحذوفة في جميع الاستعلامات.
س ما مدى تفصيل مستندات تصميم المشروع؟
ج يجب أن تكون مفصلة بما يكفي لأعضاء الفريق الجدد لفهم الصورة الكبرة للمنظومة. يجب أن تتضمن: المتطلبات التجارية، خيارات التقنيات والأساس المنطقي وراءها، تصميم قاعدة البيانات، مواصفات واجهة برمجة التطبيقات، والمتطلبات غير الوظيفية. لا حاجة لتضمين تفاصيل تنفيذ الكود—الكود نفسه يعمل كأكثر التوثيق تفصيلاً.

📖 ملخص


📝 تمارين

  1. مهمة أساسية (الصعوبة: ⭐): أكمل مستند تحليل متطلبات OrderFlow، مع إدراج جميع قصص المستخدمين ونقاط نهاية واجهة برمجة التطبيقات.

  2. مسألة متقدمة (الصعوبة: ⭐⭐): أكمل تصميم ER لقاعدة البيانات وعبارات DDL لإنشاء الجداول، بما في ذلك جميع الفهارس. صمم تنسيق استجابة معياري ونظام رموز الأخطاء.

  3. تحدٍ (الصعوبة: ⭐⭐⭐): استخدم SpringDoc OpenAPI لكتابة مواصفات واجهة برمجة التطبيقات وإنشاء صفحة توثيق تفاعلية لواجهة برمجة التطبيقات. فكر في كيفية إبقاء توثيق واجهة برمجة التطبيقات متزامنًا مع تنفيذ الكود.

Web-Tutorial.com

فريق Web-Tutorial التقني

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

100%