#015 — Software Design | تصميم البرمجيات
بعد أن نفهم المشكلة، نجمع المتطلبات، نحلل العمليات، ونحدد المخاطر… يأتي سؤال مهم جدًا:
كيف سنحوّل كل هذا الفهم إلى نظام يمكن بناؤه فعليًا؟
هنا تبدأ مرحلة Software Design — تصميم البرمجيات.
التحليل يخبرنا:
WHAT? — ماذا يجب أن يفعل النظام؟
أما التصميم فيجيب:
HOW? — كيف سنبني النظام ليحقق ذلك؟
ولهذا فالتسلسل الطبيعي ليس:
Requirements → Code
بل:
Requirements → Design → Code
في مرحلة التصميم نبدأ بتحديد مكونات النظام، مسؤولية كل مكوّن، طريقة انتقال البيانات، كيفية التواصل بين الأجزاء، نقاط اتخاذ القرار، والقيود التقنية والأمنية والأدائية التي يجب مراعاتها.
وهنا يظهر مفهومان مهمان:
HLD — High-Level Design ينظر إلى الصورة الكبيرة: Architecture، Services، Database، External Systems، وكيف تتواصل المكونات.
بينما LLD — Low-Level Design يدخل إلى التفاصيل: Classes، Methods، Interfaces، Data Structures، Validation، وError Handling.
لكن التصميم الجيد لا يعني إضافة أكبر عدد ممكن من الطبقات والأنماط والمكونات.
بل يعني أن تعطي كل جزء مسؤولية واضحة.
فبدل أن يكون لدينا Component واحد مسؤول عن Login وOrders وPayments وNotifications وكل شيء آخر، نفصل المسؤوليات بطريقة تجعل النظام أوضح وأسهل في التغيير والاختبار.
وهنا تظهر قاعدة مهمة:
High Cohesion + Low Coupling
أي أن الأشياء المرتبطة منطقيًا تبقى معًا، وفي الوقت نفسه نقلل الاعتماد غير الضروري بين المكونات.
مثال:
لدينا Requirement تقول:
"يجب أن يستطيع العميل إنشاء طلب ودفع قيمته إلكترونيًا."
قد تتحول في التصميم إلى:
Client App → Order Controller → Order Service → Payment Service → Payment Gateway → Database → Notification Service
متطلب واحد فقط، لكنه يحتاج عدة مكونات تتعاون لتحقيق الهدف.
لكن السؤال الأهم:
كيف أعرف أن تصميمي جيد؟
التصميم الجيد عادةً يكون قابلًا للصيانة Maintainable، وقابلًا للتوسع Scalable، وقابلًا للاختبار Testable، وآمنًا Secure، وفعّالًا Performant، وبسيطًا بالقدر المناسب Simple.
لأن التصميم الجيد لا يحل مشكلة اليوم فقط؛ بل يجعل تغيير النظام غدًا أسهل وأقل تكلفة.
وفي المقابل، هناك أخطاء تصميمية شائعة يجب الحذر منها مثل: Overengineering، Tight Coupling، God Class، Premature Optimization، Ignoring Failure Cases، وDesigning Without Requirements.
لذلك:
Good Design ≠ More Complexity
بل:
Good Design = Right Complexity
لا تجعل الكود هو المكان الذي تكتشف فيه تصميم النظام للمرة الأولى.
Think → Design → Then Code
ويمكن تلخيص الرحلة هكذا:
Clear Requirements + Good Design = Cleaner Code
سؤال للنقاش:
لو كنت تصمم متجرًا إلكترونيًا، هل ستضع Orders وPayments وNotifications داخل Service واحدة، أم ستفصل مسؤولياتها؟ ولماذا؟
المنشور القادم:
#016 — Software Architecture
ما الفرق بين التصميم والمعمارية؟ وكيف نحدد الشكل العام للنظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SoftwareDesign #SystemDesign #HighLevelDesign #LowLevelDesign #HLD #LLD #SeparationOfConcerns #CleanArchitecture #SoftwareArchitecture #SystemAnalysis #RequirementsEngineering #BackendDevelopment #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_البرمجيات #معمارية_البرمجيات #تطوير_البرمجيات
بعد أن نفهم المشكلة، نجمع المتطلبات، نحلل العمليات، ونحدد المخاطر… يأتي سؤال مهم جدًا:
كيف سنحوّل كل هذا الفهم إلى نظام يمكن بناؤه فعليًا؟
هنا تبدأ مرحلة Software Design — تصميم البرمجيات.
التحليل يخبرنا:
WHAT? — ماذا يجب أن يفعل النظام؟
أما التصميم فيجيب:
HOW? — كيف سنبني النظام ليحقق ذلك؟
ولهذا فالتسلسل الطبيعي ليس:
Requirements → Code
بل:
Requirements → Design → Code
في مرحلة التصميم نبدأ بتحديد مكونات النظام، مسؤولية كل مكوّن، طريقة انتقال البيانات، كيفية التواصل بين الأجزاء، نقاط اتخاذ القرار، والقيود التقنية والأمنية والأدائية التي يجب مراعاتها.
وهنا يظهر مفهومان مهمان:
HLD — High-Level Design ينظر إلى الصورة الكبيرة: Architecture، Services، Database، External Systems، وكيف تتواصل المكونات.
بينما LLD — Low-Level Design يدخل إلى التفاصيل: Classes، Methods، Interfaces، Data Structures، Validation، وError Handling.
لكن التصميم الجيد لا يعني إضافة أكبر عدد ممكن من الطبقات والأنماط والمكونات.
بل يعني أن تعطي كل جزء مسؤولية واضحة.
فبدل أن يكون لدينا Component واحد مسؤول عن Login وOrders وPayments وNotifications وكل شيء آخر، نفصل المسؤوليات بطريقة تجعل النظام أوضح وأسهل في التغيير والاختبار.
وهنا تظهر قاعدة مهمة:
High Cohesion + Low Coupling
أي أن الأشياء المرتبطة منطقيًا تبقى معًا، وفي الوقت نفسه نقلل الاعتماد غير الضروري بين المكونات.
مثال:
لدينا Requirement تقول:
"يجب أن يستطيع العميل إنشاء طلب ودفع قيمته إلكترونيًا."
قد تتحول في التصميم إلى:
Client App → Order Controller → Order Service → Payment Service → Payment Gateway → Database → Notification Service
متطلب واحد فقط، لكنه يحتاج عدة مكونات تتعاون لتحقيق الهدف.
لكن السؤال الأهم:
كيف أعرف أن تصميمي جيد؟
التصميم الجيد عادةً يكون قابلًا للصيانة Maintainable، وقابلًا للتوسع Scalable، وقابلًا للاختبار Testable، وآمنًا Secure، وفعّالًا Performant، وبسيطًا بالقدر المناسب Simple.
لأن التصميم الجيد لا يحل مشكلة اليوم فقط؛ بل يجعل تغيير النظام غدًا أسهل وأقل تكلفة.
وفي المقابل، هناك أخطاء تصميمية شائعة يجب الحذر منها مثل: Overengineering، Tight Coupling، God Class، Premature Optimization، Ignoring Failure Cases، وDesigning Without Requirements.
لذلك:
Good Design ≠ More Complexity
بل:
Good Design = Right Complexity
لا تجعل الكود هو المكان الذي تكتشف فيه تصميم النظام للمرة الأولى.
Think → Design → Then Code
ويمكن تلخيص الرحلة هكذا:
Clear Requirements + Good Design = Cleaner Code
سؤال للنقاش:
لو كنت تصمم متجرًا إلكترونيًا، هل ستضع Orders وPayments وNotifications داخل Service واحدة، أم ستفصل مسؤولياتها؟ ولماذا؟
المنشور القادم:
#016 — Software Architecture
ما الفرق بين التصميم والمعمارية؟ وكيف نحدد الشكل العام للنظام؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SoftwareDesign #SystemDesign #HighLevelDesign #LowLevelDesign #HLD #LLD #SeparationOfConcerns #CleanArchitecture #SoftwareArchitecture #SystemAnalysis #RequirementsEngineering #BackendDevelopment #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_البرمجيات #معمارية_البرمجيات #تطوير_البرمجيات