#017 — Detailed Design | التصميم التفصيلي
بعد ما نحدد المعمارية العامة (Software Architecture) ونرسم الهيكل العالي للنظام، نوصل للسؤال اليومي اللي يسأله أي مهندس برمجيات حقيقي قبل ما يفتح الـ IDE:
"كيف سيعمل كل جزء داخل الكود فعليًا؟"
هنا يجي دور الـ Detailed Design (التصميم التفصيلي).
المعمارية تعطيك الصورة الكبيرة:
Services — Components — Database — Communication
أما التصميم التفصيلي، فينزل معك للتفاصيل الدقيقة اللي تبني عليها شغلك اليومي:
Classes — Methods — Interfaces — Data Models — Validation — Error Handling
التسلسل الطبيعي لأي نظام متين هو:
Architecture → Detailed Design → Code
الهدف هنا مش كتابة وثائق رسمية معقدة ولا رسم مخططات لمجرد الرسم، الهدف الحقيقي هو إزالة الغموض تمامًا قبل كتابة أول سطر كود.
فصل المسؤوليات داخل المكونات
لما يكون عندك مكون مثل Order Service، الخطأ الشائع اللي ينقع فيه في البداية هو تحويله لـ Class ضخم (God Object) يعمل كل شيء:
يتأكد من المدخلات، يحفظ في الدعم، ينفذ الدفع، ويرسل الإشعار!
التصميم الهندسي الصح هو توزيع المسؤوليات بشكل نظيف:
OrderController:
يستقبل الـ Request وينظم الـ HTTP Response.
OrderValidator:
يتحقق من صحة المدخلات وسلامة الـ Data Format.
OrderService:
يحتوي على الـ Business Logic الصافي فقط.
OrderRepository:
يتعامل مع طبقة البيانات وتخزينها.
PaymentService:
يدير عمليات التواصل مع بوابة الدفع.
NotificationService:
يتكفل بإرسال الإشعارات والبريد.
وهنا نطبق القاعدة الذهبية:
One Responsibility → One Clear Reason to Change
كلما كانت مسؤولية كل Class واضحة ومحددة، كلما كان النظام أسهل في الفهم، الصيانة، التعديل، والـ Unit Testing.
نمذجة التفاعل بين المكونات (Interactions)
التصميم التفصيلي لا يتوقف عند تحديد الـ Classes فقط، بل يتعداه لمعرفة كيف تتعاون هذه الأجزاء وتتواصل أثناء تنفيذ الـ Flow.
وهنا يأتي دور Sequence Diagram.
في سيناريو إنشاء طلب جديد (Create Order):
Customer → OrderController → OrderValidator → OrderService → OrderRepository → PaymentService → NotificationService
المخطط هذا يوضح لك بوضوح:
من يبدأ العملية؟
من يستدعي من؟
ما هو ترتيب الرسائل والعمليات؟
ومن المسؤول عن كل خطوة بدقة؟
تقليل التبعية والاعتماد على التجريد (Loose Coupling)
التصميم الجيد يقلل الارتباط المباشر بين التفاصيل التنفيذية.
بدل الاعتماد المباشر:
OrderService → MySQLOrderRepository
نعتمد على التجريد (Abstraction):
OrderService → OrderRepository Interface ← MySQLOrderRepository
بالمفهوم هذا، يمكنك مستقبلاً تغيير قاعدة البيانات من MySQL إلى PostgreSQL أو MongoDB، أو حتى استخدام Mock Repository أثناء كتابة الاختبارات، بدون ما تلمس سطر واحد في الـ Business Logic.
Depend on abstractions, not concrete details.
التفكير في الحالات الاستثنائية (Edge Cases)
أكبر خطأ يقع فيه المطور هو التصميم للـ Happy Path فقط:
Create Order → Payment Success → Order Confirmed
مهندس البرمجيات الخبير يسأل دائمًا الأسئلة الصعبة قبل البرمجة:
ماذا لو المنتج غير متوفر في المخزن؟
ماذا لو فشلت عملية الدفع أو انتهت الجلسة (Timeout)؟
ماذا لو تعطلت قاعدة البيانات أثناء الحفظ؟
ماذا لو فشل سيرفر الإشعارات؟
التصميم التفصيلي المتين يحدد الطرق التالية مسبقًا:
Success Flow
Alternative Flow
Failure & Exception Flow
قبل ما تتحول هذه الحالات إلى مفاجآت وأخطاء غريبة أثناء Production.
خريطة طريق التصميم التفصيلي
يمكن تلخيص رحلة Detailed Design في هذه الخطوات المتسلسلة:
Architecture
↓
Identify Classes
↓
Assign Responsibilities
↓
Define Interfaces
↓
Design Methods & Data Models
↓
Model Interactions (Sequence Diagrams)
↓
Handle Errors & Edge Cases
↓
Review Coupling & Cohesion
↓
Implement Code
المعادلة البسيطة:
Architecture + Detailed Design = Clean & Implementable Code
القاعدة التي يجب أن ترافقك دائمًا:
لا تجعل مرحلة الـ Coding هي المكان الذي تكتشف فيه تصميم النظام لأول مرة.
Think → Model → Detail → Code
سؤال للنقاش:
لو مر عليك كود في مشروعك الحالي فيه OrderService يقوم بإنشاء الطلب، الحفظ، الدفع، وإرسال الإشعارات... كيف تبدأ بالتدرج في إعادة هيكلته (Refactoring) وتوزيع مسؤولياته بدون ما تكسر الـ Features الشغالة؟
المنشور القادم:
#018 — Design Principles
بعد ما نحدد المعمارية العامة (Software Architecture) ونرسم الهيكل العالي للنظام، نوصل للسؤال اليومي اللي يسأله أي مهندس برمجيات حقيقي قبل ما يفتح الـ IDE:
"كيف سيعمل كل جزء داخل الكود فعليًا؟"
هنا يجي دور الـ Detailed Design (التصميم التفصيلي).
المعمارية تعطيك الصورة الكبيرة:
Services — Components — Database — Communication
أما التصميم التفصيلي، فينزل معك للتفاصيل الدقيقة اللي تبني عليها شغلك اليومي:
Classes — Methods — Interfaces — Data Models — Validation — Error Handling
التسلسل الطبيعي لأي نظام متين هو:
Architecture → Detailed Design → Code
الهدف هنا مش كتابة وثائق رسمية معقدة ولا رسم مخططات لمجرد الرسم، الهدف الحقيقي هو إزالة الغموض تمامًا قبل كتابة أول سطر كود.
فصل المسؤوليات داخل المكونات
لما يكون عندك مكون مثل Order Service، الخطأ الشائع اللي ينقع فيه في البداية هو تحويله لـ Class ضخم (God Object) يعمل كل شيء:
يتأكد من المدخلات، يحفظ في الدعم، ينفذ الدفع، ويرسل الإشعار!
التصميم الهندسي الصح هو توزيع المسؤوليات بشكل نظيف:
OrderController:
يستقبل الـ Request وينظم الـ HTTP Response.
OrderValidator:
يتحقق من صحة المدخلات وسلامة الـ Data Format.
OrderService:
يحتوي على الـ Business Logic الصافي فقط.
OrderRepository:
يتعامل مع طبقة البيانات وتخزينها.
PaymentService:
يدير عمليات التواصل مع بوابة الدفع.
NotificationService:
يتكفل بإرسال الإشعارات والبريد.
وهنا نطبق القاعدة الذهبية:
One Responsibility → One Clear Reason to Change
كلما كانت مسؤولية كل Class واضحة ومحددة، كلما كان النظام أسهل في الفهم، الصيانة، التعديل، والـ Unit Testing.
نمذجة التفاعل بين المكونات (Interactions)
التصميم التفصيلي لا يتوقف عند تحديد الـ Classes فقط، بل يتعداه لمعرفة كيف تتعاون هذه الأجزاء وتتواصل أثناء تنفيذ الـ Flow.
وهنا يأتي دور Sequence Diagram.
في سيناريو إنشاء طلب جديد (Create Order):
Customer → OrderController → OrderValidator → OrderService → OrderRepository → PaymentService → NotificationService
المخطط هذا يوضح لك بوضوح:
من يبدأ العملية؟
من يستدعي من؟
ما هو ترتيب الرسائل والعمليات؟
ومن المسؤول عن كل خطوة بدقة؟
تقليل التبعية والاعتماد على التجريد (Loose Coupling)
التصميم الجيد يقلل الارتباط المباشر بين التفاصيل التنفيذية.
بدل الاعتماد المباشر:
OrderService → MySQLOrderRepository
نعتمد على التجريد (Abstraction):
OrderService → OrderRepository Interface ← MySQLOrderRepository
بالمفهوم هذا، يمكنك مستقبلاً تغيير قاعدة البيانات من MySQL إلى PostgreSQL أو MongoDB، أو حتى استخدام Mock Repository أثناء كتابة الاختبارات، بدون ما تلمس سطر واحد في الـ Business Logic.
Depend on abstractions, not concrete details.
التفكير في الحالات الاستثنائية (Edge Cases)
أكبر خطأ يقع فيه المطور هو التصميم للـ Happy Path فقط:
Create Order → Payment Success → Order Confirmed
مهندس البرمجيات الخبير يسأل دائمًا الأسئلة الصعبة قبل البرمجة:
ماذا لو المنتج غير متوفر في المخزن؟
ماذا لو فشلت عملية الدفع أو انتهت الجلسة (Timeout)؟
ماذا لو تعطلت قاعدة البيانات أثناء الحفظ؟
ماذا لو فشل سيرفر الإشعارات؟
التصميم التفصيلي المتين يحدد الطرق التالية مسبقًا:
Success Flow
Alternative Flow
Failure & Exception Flow
قبل ما تتحول هذه الحالات إلى مفاجآت وأخطاء غريبة أثناء Production.
خريطة طريق التصميم التفصيلي
يمكن تلخيص رحلة Detailed Design في هذه الخطوات المتسلسلة:
Architecture
↓
Identify Classes
↓
Assign Responsibilities
↓
Define Interfaces
↓
Design Methods & Data Models
↓
Model Interactions (Sequence Diagrams)
↓
Handle Errors & Edge Cases
↓
Review Coupling & Cohesion
↓
Implement Code
المعادلة البسيطة:
Architecture + Detailed Design = Clean & Implementable Code
القاعدة التي يجب أن ترافقك دائمًا:
لا تجعل مرحلة الـ Coding هي المكان الذي تكتشف فيه تصميم النظام لأول مرة.
Think → Model → Detail → Code
سؤال للنقاش:
لو مر عليك كود في مشروعك الحالي فيه OrderService يقوم بإنشاء الطلب، الحفظ، الدفع، وإرسال الإشعارات... كيف تبدأ بالتدرج في إعادة هيكلته (Refactoring) وتوزيع مسؤولياته بدون ما تكسر الـ Features الشغالة؟
المنشور القادم:
#018 — Design Principles
كيف تساعدنا مبادئ مثل SRP و OCP و Dependency Inversion على بناء تصميم مرن، قابل للتوسع والتغيير بكل سهولة؟
م.طارق العمري
Software Engineer| Backend Developer
#SoftwareEngineering #DetailedDesign #SoftwareDesign #SystemDesign #CleanArchitecture #SOLID #BackendDevelopment #CleanCode #SoftwareEngineer #هندسة_البرمجيات #التصميم_التفصيلي #تطوير_البرمجيات
م.طارق العمري
Software Engineer| Backend Developer
#SoftwareEngineering #DetailedDesign #SoftwareDesign #SystemDesign #CleanArchitecture #SOLID #BackendDevelopment #CleanCode #SoftwareEngineer #هندسة_البرمجيات #التصميم_التفصيلي #تطوير_البرمجيات
لكل بداية نهاية، ولكل نهاية بداية جديدة.. واليوم أعلن رسمياً تخرجي!
لم تكن رحلة الدراسة مجرد سنوات مرت، بل كانت تجربة مليئة بالتحديات والتعلم المستمر. ولأن أفضل طريقة لتتويج هذه الرحلة هي العمل التطبيقي، حرصت على أن أختمها ببناء مشروع متكامل يعبر عن شغفي في مجال التطوير والبرمجة.
في مستوى ثالث بدأت بعمل Portfolio ولكن بالتقينات التي كنت أعرفها حينها وكان المشروع ثابت Static
بعد تطورنا وتطور معرفتنا بالباك ودمج الذكاء الاصطناعي
قمت ببناء بورتفوليو (Portfolio) متكامل يضم:
واجهة متكاملة مع Backend منفصل: لبناء معمارية برمجية قوية ومستقلة.
لوحة تحكم (Dashboard): وإدارة كاملة للمحتوى والبيانات.
الموقع الرئيسي العام وصفحاته
مساعد ذكي (AI Assistant): للتفاعل مع الزوار وتقديم تجر استخدام حديثة.
خدمات متعددة: عرض مشاريعي البرمجية، مدونة تقنية، عرض الـ CV التفاعلي، استعراض التقنيات المستخدمة، وغيرها الكثير.
شكرًا لكل من دعمني في هذه الرحلة من عائلة، أصدقاء، وأساتذة. هذه مجرد الخطوة الأولى، والحماس في أعلاه لما هو قادم!
📌 يمكنكم الاطلاع على المشروع عبر الرابط
https://tareq-frontend.onrender.com
م.طارق فضل العمري
لم تكن رحلة الدراسة مجرد سنوات مرت، بل كانت تجربة مليئة بالتحديات والتعلم المستمر. ولأن أفضل طريقة لتتويج هذه الرحلة هي العمل التطبيقي، حرصت على أن أختمها ببناء مشروع متكامل يعبر عن شغفي في مجال التطوير والبرمجة.
في مستوى ثالث بدأت بعمل Portfolio ولكن بالتقينات التي كنت أعرفها حينها وكان المشروع ثابت Static
بعد تطورنا وتطور معرفتنا بالباك ودمج الذكاء الاصطناعي
قمت ببناء بورتفوليو (Portfolio) متكامل يضم:
واجهة متكاملة مع Backend منفصل: لبناء معمارية برمجية قوية ومستقلة.
لوحة تحكم (Dashboard): وإدارة كاملة للمحتوى والبيانات.
الموقع الرئيسي العام وصفحاته
مساعد ذكي (AI Assistant): للتفاعل مع الزوار وتقديم تجر استخدام حديثة.
خدمات متعددة: عرض مشاريعي البرمجية، مدونة تقنية، عرض الـ CV التفاعلي، استعراض التقنيات المستخدمة، وغيرها الكثير.
شكرًا لكل من دعمني في هذه الرحلة من عائلة، أصدقاء، وأساتذة. هذه مجرد الخطوة الأولى، والحماس في أعلاه لما هو قادم!
📌 يمكنكم الاطلاع على المشروع عبر الرابط
https://tareq-frontend.onrender.com
م.طارق فضل العمري
👏3
برومو | دفعة الظل التقني - ٢٠٢٦
لمشاهدة حفل تخرج دفعة الظل التقني
الخاص بطلاب
علوم الحاسوب وتقنية المعلومات - جامعة إب ٢٠٢٦م
تابعوا البث المباشر على اليوتيوب غداً
الساعة التاسعة صباحاً بث مباشر
لمن لا يستطيع الحضور.
https://youtube.com/@algunaidmedia?si=yaNDro2hEbCKho_z
لمشاهدة حفل تخرج دفعة الظل التقني
الخاص بطلاب
علوم الحاسوب وتقنية المعلومات - جامعة إب ٢٠٢٦م
تابعوا البث المباشر على اليوتيوب غداً
الساعة التاسعة صباحاً بث مباشر
لمن لا يستطيع الحضور.
https://youtube.com/@algunaidmedia?si=yaNDro2hEbCKho_z
❤1
#018 — Database Design | تصميم قواعد البيانات
أي نظام ناجح لا يعتمد فقط على كود جيد، بل يحتاج إلى بيانات منظمة ومصممة بشكل صحيح من البداية.
وهنا يأتي دور:
Database Design — تصميم قواعد البيانات
الفكرة ليست أن تنشئ Tables كثيرة، بل أن تسأل أولًا:
ما البيانات التي أحتاجها فعلًا؟ وكيف ترتبط ببعضها؟
لأن التصميم السيئ قد يؤدي إلى:
تكرار البيانات، صعوبة التعديل، أخطاء في العلاقات، بطء الاستعلامات، ومشاكل تظهر كلما كبر النظام.
لذلك نبدأ عادةً بـ:
Requirements → Entities → Attributes → Keys → Relationships → ERD → Database
فمثلًا في متجر إلكتروني قد نحدد:
Customer — العميل
Product — المنتج
Order — الطلب
Payment — الدفع
Category — التصنيف
Address — العنوان
ثم نحول كل مفهوم مهم إلى Entity، وبعدها نحدد خصائصه.
مثلًا:
Customer
id
name
email
phone
وهنا تأتي المفاتيح:
Primary Key — PK
يميز كل Record بشكل فريد.
Foreign Key — FK
يربط البيانات بين الجداول.
وباختصار:
PK identifies. FK connects.
لكن البيانات لا تعيش منفصلة، لذلك نحتاج إلى فهم Relationships:
1:1 — One-to-One
مستخدم واحد ملف شخصي واحد.
1:N — One-to-Many
عميل واحد → عدة طلبات.
M:N — Many-to-Many
الطلب يحتوي عدة منتجات، والمنتج قد يظهر في عدة طلبات.
وفي حالة M:N نستخدم غالبًا جدولًا وسيطًا مثل:
OrderItems
حتى نحافظ على تصميم منطقي ومنظم.
ثم يأتي دور:
ERD — Entity Relationship Diagram
وهو الخريطة التي توضح:
Entities
Attributes
Primary Keys
Foreign Keys
Relationships
Cardinality
قبل أن تبدأ كتابة SQL.
لكن التصميم لا يتوقف هنا.
نحتاج أيضًا إلى Normalization — التطبيع لتقليل التكرار ووضع كل معلومة في المكان الصحيح.
والقاعدة الجميلة هنا:
Store each fact in the right place.
ثم نضيف عناصر تجعل قاعدة البيانات أكثر موثوقية:
Constraints
مثل NOT NULL وUNIQUE وCHECK وFOREIGN KEY.
Data Types
اختيار النوع المناسب لكل قيمة.
Indexes
لتسريع البحث والاستعلامات عند استخدامها بشكل صحيح.
Naming
أسماء واضحة ومتناسقة.
Integrity
الحفاظ على صحة وترابط البيانات.
Performance
تصميم يناسب طريقة استخدام النظام فعلًا.
ويمكن تلخيص الرحلة كاملة هكذا:
Understand Data
↓
Identify Entities
↓
Define Attributes
↓
Choose Primary Keys
↓
Define Relationships
↓
Draw ERD
↓
Normalize
↓
Add Constraints & Indexes
↓
Validate with Real Scenarios
ثم المعادلة:
Good Data Model → Reliable Database → Better System
وأهم نصيحة:
لا تصمم قاعدة البيانات لتناسب الشاشة الحالية فقط.
صمّمها لتمثل البيانات الحقيقية والعلاقات الحقيقية داخل النظام.
Understand → Model → Relate → Normalize → Implement
سؤال للنقاش:
في متجر إلكتروني، لماذا لا نضع المنتجات مباشرة داخل جدول Orders؟
ولماذا نحتاج جدولًا مثل OrderItems؟
م. طارق العمري
Software Engineer | Backend Developer
#DatabaseDesign #Database #DataModeling #ERD #SQL #Normalization #PrimaryKey #ForeignKey #DatabaseRelationships #BackendDevelopment #SoftwareEngineering #SystemDesign #SoftwareDeveloper #SoftwareEngineer #تصميم_قواعد_البيانات #قواعد_البيانات #هندسة_البرمجيات #تطوير_البرمجيات
أي نظام ناجح لا يعتمد فقط على كود جيد، بل يحتاج إلى بيانات منظمة ومصممة بشكل صحيح من البداية.
وهنا يأتي دور:
Database Design — تصميم قواعد البيانات
الفكرة ليست أن تنشئ Tables كثيرة، بل أن تسأل أولًا:
ما البيانات التي أحتاجها فعلًا؟ وكيف ترتبط ببعضها؟
لأن التصميم السيئ قد يؤدي إلى:
تكرار البيانات، صعوبة التعديل، أخطاء في العلاقات، بطء الاستعلامات، ومشاكل تظهر كلما كبر النظام.
لذلك نبدأ عادةً بـ:
Requirements → Entities → Attributes → Keys → Relationships → ERD → Database
فمثلًا في متجر إلكتروني قد نحدد:
Customer — العميل
Product — المنتج
Order — الطلب
Payment — الدفع
Category — التصنيف
Address — العنوان
ثم نحول كل مفهوم مهم إلى Entity، وبعدها نحدد خصائصه.
مثلًا:
Customer
id
name
phone
وهنا تأتي المفاتيح:
Primary Key — PK
يميز كل Record بشكل فريد.
Foreign Key — FK
يربط البيانات بين الجداول.
وباختصار:
PK identifies. FK connects.
لكن البيانات لا تعيش منفصلة، لذلك نحتاج إلى فهم Relationships:
1:1 — One-to-One
مستخدم واحد ملف شخصي واحد.
1:N — One-to-Many
عميل واحد → عدة طلبات.
M:N — Many-to-Many
الطلب يحتوي عدة منتجات، والمنتج قد يظهر في عدة طلبات.
وفي حالة M:N نستخدم غالبًا جدولًا وسيطًا مثل:
OrderItems
حتى نحافظ على تصميم منطقي ومنظم.
ثم يأتي دور:
ERD — Entity Relationship Diagram
وهو الخريطة التي توضح:
Entities
Attributes
Primary Keys
Foreign Keys
Relationships
Cardinality
قبل أن تبدأ كتابة SQL.
لكن التصميم لا يتوقف هنا.
نحتاج أيضًا إلى Normalization — التطبيع لتقليل التكرار ووضع كل معلومة في المكان الصحيح.
والقاعدة الجميلة هنا:
Store each fact in the right place.
ثم نضيف عناصر تجعل قاعدة البيانات أكثر موثوقية:
Constraints
مثل NOT NULL وUNIQUE وCHECK وFOREIGN KEY.
Data Types
اختيار النوع المناسب لكل قيمة.
Indexes
لتسريع البحث والاستعلامات عند استخدامها بشكل صحيح.
Naming
أسماء واضحة ومتناسقة.
Integrity
الحفاظ على صحة وترابط البيانات.
Performance
تصميم يناسب طريقة استخدام النظام فعلًا.
ويمكن تلخيص الرحلة كاملة هكذا:
Understand Data
↓
Identify Entities
↓
Define Attributes
↓
Choose Primary Keys
↓
Define Relationships
↓
Draw ERD
↓
Normalize
↓
Add Constraints & Indexes
↓
Validate with Real Scenarios
ثم المعادلة:
Good Data Model → Reliable Database → Better System
وأهم نصيحة:
لا تصمم قاعدة البيانات لتناسب الشاشة الحالية فقط.
صمّمها لتمثل البيانات الحقيقية والعلاقات الحقيقية داخل النظام.
Understand → Model → Relate → Normalize → Implement
سؤال للنقاش:
في متجر إلكتروني، لماذا لا نضع المنتجات مباشرة داخل جدول Orders؟
ولماذا نحتاج جدولًا مثل OrderItems؟
م. طارق العمري
Software Engineer | Backend Developer
#DatabaseDesign #Database #DataModeling #ERD #SQL #Normalization #PrimaryKey #ForeignKey #DatabaseRelationships #BackendDevelopment #SoftwareEngineering #SystemDesign #SoftwareDeveloper #SoftwareEngineer #تصميم_قواعد_البيانات #قواعد_البيانات #هندسة_البرمجيات #تطوير_البرمجيات
❤1