تمرين عملي شامل: تصميم مشروع OrderFlow
تصميم المشروع هو المخطط للتطوير—المتطلبات تحدد الاتجاه، واختيار التقنيات يحدد المنهج، والتصميم يحدد البنية. الإعداد هو نصف المعركة.
1. ما ستتعلمه
- اقترح Charlie المتطلبات التجارية التالية: أربعة وحدات رئيسية—إدارة المستخدمين وإدارة المنتجات وإدارة الطلبات وإدارة المدفوعات
- قرارات اختيار التقنيات: WebMVC مقابل WebFlux، Session مقابل JWT، ذاكرة التخزين المؤقت المحلية مقابل Redis
- تصميم مخطط ER لقاعدة البيانات: هياكل جداول User وProduct وOrder وOrderItem وPayment
- تصميم مواصفات واجهة برمجة التطبيقات RESTful: تسمية URI / التحكم في الإصدار / الترقيم والفرز / HATEOAS
- Alice تطور خطة التطوير وتعين مسؤوليات كل وحدة
2. قصة حقيقية لمدير منتج
(1) نقطة الألم: الفجوة بين المتطلبات والكود
جاء Charlie إلى Alice بمستند متطلبات غامض: "نحتاج نظام إدارة طلبات تجارة إلكترونية." سألت Alice: "ما الميزات المطلوبة؟ ما أدوار المستخدمين المختلفة؟ ما سمات المنتجات؟ كيف ترتبط الطلبات والمدفوعات؟" لم يستطع Charlie الشرح بوضوح، فاضطرت Alice للتخمين بناءً على خبرتها. نتيجة لذلك، بعد أسبوعين من التطوير، قال Charlie: "هذا ليس ما أردته."
(2) حلول تصميم المنظومة
صمم أولاً، ثم طوّر—تحليل المتطلبات ← اختيار التقنيات ← تصميم قاعدة البيانات ← مواصفات واجهة برمجة التطبيقات. أكد كل خطوة مع Charlie:
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) ▶ مثال: قصة المستخدم
بصفتي CUSTOMER، أريد:
- تصفح والبحث عن المنتجات
- إضافة منتجات إلى سلة التسوق (مستقبلاً)
- تقديم طلب بعناصر متعددة
- عرض سجل طلباتي
- إلغاء طلب غير مدفوع خلال 30 دقيقة
- الدفع مقابل طلب
- عرض حالة الدفع
بصفتي ADMIN، أريد:
- إدارة المنتجات (CRUD)
- عرض جميع الطلبات
- إلغاء أي طلب
- معالجة الاستردادات
- عرض إحصائيات الأعمال
الناتج:
التنفيذ ناجح
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 الكامل
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 لإنشاء الجداول
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)
);
الناتج:
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) ▶ مثال: تنسيق الاستجابة المعياري
// استجابة ناجحة
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
) {}
الناتج:
// التنفيذ ناجح
(3) ▶ مثال: معاملات الترقيم والفرز
# قائمة المنتجات مع الترقيم والفرز والتصفية
GET /api/v1/products?page=0&size=20&sort=price,desc&category=electronics&minPrice=100&maxPrice=999
الناتج:
# تم تنفيذ الأمر بنجاح
7. خطة التطوير وتعيينات الوحدات
(1) ▶ مثال: خطة التكرار
| Sprint | التكرار | الهدف | المخرجات |
|---|---|---|---|
| Sprint 1 | الأسابيع 1-2 | الإطار الأساسي | هيكل المشروع + المصادقة + CRUD المنتجات |
| Sprint 2 | الأسابيع 3-4 | الأعمال الأساسية | وحدة الطلبات + المعاملات + التحقق + الاستثناءات |
| Sprint 3 | الأسابيع 5-6 | الميزات المتقدمة | التخزين المؤقت + المهام المجدولة + الإشعارات غير المتزامنة |
| Sprint 4 | الأسابيع 7-8 | العمليات والنشر | Docker + K8s + المراقبة والتنبيهات |
8. مثال شامل: مستند تصميم مشروع OrderFlow
# مستند تصميم منظومة 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 + JWT + تخزين مؤقت ثنائي المستوى + MySQL + JPA
- تصميم ER لقاعدة البيانات بخمسة جداول؛ فهارس تغطي الاستعلامات عالية التردد
- مواصفات واجهة برمجة التطبيقات تعير تسمية URI والتحكم في الإصدار والترقيم والفرز وتنسيقات الاستجابة
- خطة التطوير مقسمة إلى 4 sprints، كل sprint يستمر أسبوعين
- مستندات تصميم المشروع تعمل كـ "عقد" لفريق التطوير
📝 تمارين
-
مهمة أساسية (الصعوبة: ⭐): أكمل مستند تحليل متطلبات OrderFlow، مع إدراج جميع قصص المستخدمين ونقاط نهاية واجهة برمجة التطبيقات.
-
مسألة متقدمة (الصعوبة: ⭐⭐): أكمل تصميم ER لقاعدة البيانات وعبارات DDL لإنشاء الجداول، بما في ذلك جميع الفهارس. صمم تنسيق استجابة معياري ونظام رموز الأخطاء.
-
تحدٍ (الصعوبة: ⭐⭐⭐): استخدم SpringDoc OpenAPI لكتابة مواصفات واجهة برمجة التطبيقات وإنشاء صفحة توثيق تفاعلية لواجهة برمجة التطبيقات. فكر في كيفية إبقاء توثيق واجهة برمجة التطبيقات متزامنًا مع تنفيذ الكود.



