هندسة برمجيات أكتوبر 6, 2025
هل يمكن لأي مشروع تطوير برمجي أن ينجح دون أن يمتلك خريطة طريق تقنية واضحة؟
في عالم تطوير الأنظمة (System Development)، لا يُبنى النجاح على الكود وحده، بل على وضوح الرؤية.
وهنا يأتي دور التصميم الأولي للبرمجيات (High-Level Design)، تلك المرحلة المفصلية التي تربط بين تحليل المتطلبات وتنفيذ الحلول.
في هندسة البرمجيات (Software Engineering) ومعمارية الحلول (Solution Architecture)، يمثل التصميم الأولي حجر الأساس الذي يضمن أن كل قرار تقني له مبرر، وكل مكون في النظام يخدم غاية محددة.
ما المقصود بالتصميم الأولي للبرمجيات (High-Level Design)؟
التصميم الأولي هو الوثيقة أو المرحلة التي تُترجم فيها متطلبات النظام (System Requirements) إلى بنية تصميمية واضحة (Architectural Blueprint) تحدد مكونات النظام الرئيسية وكيف تتفاعل فيما بينها.
يمكن اعتباره الجسر الذي يصل بين ما يريد العميل تحقيقه وبين ما سينفذه فريق التطوير فعلياً.
يُركّز التصميم الأولي على الصورة الشاملة — من سيقوم بماذا، وكيف ستتحدث المكونات مع بعضها — دون الخوض في تفاصيل الكود أو منطق التنفيذ الجزئي. وهذا ما يميّزه عن التصميم التفصيلي (Low-Level Design)، الذي يصف كيفية بناء كل مكون على حدة.
أهداف التصميم الأولي ودوره في نجاح المشاريع
لا تُكتب وثيقة التصميم الأولي لمجرد الالتزام بالمنهجية، بل لأنها تؤدي أدواراً جوهرية في نجاح المشروع:
- توحيد الرؤية التقنية بين جميع أعضاء الفريق. مثل أن فريق تطوير الواجهات أو البوابة Portal يحتاج أن يفهم النظام الرئيسي Backend وكذلك فريق التكامل Integration يجب أن يفهم الجميع وهذا لا يتاتى ألا من خلال فهمهم للتصميم الأولي HLD.
- المساعدة في اتخاذ قرارات معمارية مبكرة تقلل المخاطر لاحقاً.
- تحديد نقاط التكامل (Integration Points) بدقة منذ البداية.
- تحسين قابلية التطوير (Scalability) والصيانة (Maintainability).
- ضمان اتساق العمل بين فرق التحليل، التصميم، والتطوير.
- يضمن التصميم الأولى أن تستخدم مكونات برمجية موجودة مسبقاً في المنظمة بدلا من شراء أو إعادة تطوير مكونات مكررة. هذا كفيل برفع العائد على الاستثمار ROI في الحلول المطورة
في المؤسسات الكبيرة أو المشاريع المعقدة، تصبح وثيقة التصميم الأولي مرجعاً حيوياً لكل من مهندس الحلول ومدير التطوير وفرق الاختبار وحتى إدارة الأمن السيبراني.
المكونات الأساسية للتصميم الأولي
عند إعداد وثيقة التصميم الأولي، هناك عناصر رئيسية يجب أن تتضمنها:
- بنية النظام (System Architecture)
تحديد الطبقات الرئيسة (مثل طبقة واجهة المستخدم Front-End، طبقة الخدمة وهي التي تمثل من خلال Workflow مثلاً، ولا ننسى طبقة البيانات). - مخططات تدفق البيانات (Data Flow Diagrams)
لتوضيح كيف تنتقل البيانات بين المكونات. - الواجهات (Interfaces)
تعريف نقاط التكامل بين الأنظمة والخدمات الداخلية والخارجية. - اختيارات التقنية (Technology Stack)
تحديد الأطر (Frameworks)، لغات البرمجة، وقواعد البيانات المستخدمة. - القيود التقنية (Constraints)
مثل الأداء، الأمن، التوافر العالي، أو الامتثال للأنظمة المحلية. مثال واقعي على ذلك هو الإلتزام بأن يكون الدخول للنظام عن طريق خدمة النفاذ الوطني. - الافتراضات (Assumptions)
الأمور التي تم البناء عليها أثناء إعداد التصميم. مثال واقعي شاهدته في عدة جهات هو أن يجعل وظائف تطبيق الويب محدودة حتى يدفع الجهات المستخدمة له إلى الاعتماد أكثر على خدمات الويب Web Service وذلك لتوفير تكاليف التطوير الدوري لتطبيق الويب.
الفرق بين التصميم الأولي (HLD) والتصميم التفصيلي (LLD)
رغم أن التصميمين يُكملان بعضهما، إلا أن لكل منهما نطاقاً وأهدافاً مختلفة. أيضاً دعني اتوسع بتوضيح الفروقات بين التصميم الأولى HLD وأنواع التصميم التقني الأخرى.
ستجد في الجدول التالي ما يوضح لك مقارنة عملية بين مختلف أنواع التصميم:
| النوع | الهدف | متى يُستخدم | مخرجاته |
|---|---|---|---|
| التصميم الأولي (High-Level Design – HLD) | تحديد البنية العامة ومكونات النظام | بعد تحليل المتطلبات | وثيقة معمارية توضّح المكونات والعلاقات بينها |
| التصميم التفصيلي (Low-Level Design – LLD) | شرح تفاصيل المكونات الداخلية وكيفية عمل كل مكون. ويقوم به مهندس البرمجيات. | بعد اعتماد HLD | مخططات الفئات (Class Diagrams)، التسلسل (Sequence Diagrams)، وبنية البيانات |
| تصميم الواجهة (UI/UX Design) | بناء تجربة المستخدم والواجهات التفاعلية | بالتوازي مع بدء التطوير | نماذج أولية وشاشات تفاعلية Mockup |
| تصميم البيانات (Data Design) | تحديد هياكل البيانات والعلاقات بين الجداول | غالباً يتم بعد HLD | مخططات ERD وبنية قاعدة البيانات |
| تصميم الأمان (Security Design) | تحديد ضوابط الوصول والحماية والتشفير | متوازي مع التصميم العام | سياسات IAM ونماذج Threat Modeling |
دور مهندس الحلول في إعداد التصميم الأولي
مهندس الحلول (Solution Architect) هو المسؤول عن تحويل متطلبات العمل إلى نموذج تصميمي واقعي.
دوره لا يقتصر على رسم المخططات، بل يمتد إلى اتخاذ قرارات استراتيجية تشمل:
- اختيار المعمارية المناسبة (Monolithic، Microservices، Serverless).
- تحديد استراتيجيات التكامل بين الأنظمة.
- موازنة المتطلبات الوظيفية (Functional Requirements) مع المتطلبات غير الوظيفية (Non-Functional Requirements).
- ضمان توافق الحل مع معايير الأمن والأداء والامتثال التنظيمي.
المهندس الجيد لا يكتب تصميماً مثالياً على الورق، بل يصمم نظاماً يمكن لفريق التطوير تنفيذه بثقة ووضوح مع ضمان تحقق الإلتزام والامتثال باللوائح التنظيمية.
مثال تطبيقي: التصميم الأولي HLD لخدمة التحويل الدولي للأموال
لنفترض أن أحد البنوك قرر تطوير خدمة التحويل الدولي للأموال داخل تطبيقه. طبعا يصعب أن نطبق كتابة تصميم اولي HLD ولكن الهدف من المثال ان تتعرف على مكونات ما يكتب في وثيقة التصميم الأولي. في هذه الحالة، يتضمن التصميم الأولي:
- المكونات الأساسية: واجهة المستخدم (Mobile App)، خادم المعالجة (Backend Service)، بوابة التكامل مع البنوك الخارجية (Integration Layer).
- نقاط التكامل:
- مع أنظمة مكافحة غسل الأموال (AML Systems).
- مع مزودي الصرف الأجنبي (FX Providers).
- مع نظام التنبيهات والإشعارات.
- القيود التقنية:
- توافق مع معايير SWIFT وISO 20022.
- تشفير البيانات أثناء التحويل (Encryption in Transit).
- زمن معالجة لا يتجاوز 5 ثوانٍ للتحويل الواحد.
بهذه الرؤية، يصبح التصميم الأولي هو المرجع الذي يُحدد كيف سيتفاعل كل جزء من النظام لضمان تجربة موثوقة وآمنة للمستخدم.
التصميم الأولي في بيئات Agile وDevOps
رغم أن منهجيات Agile لا تُحب التوثيق المبالغ فيه، إلا أن التصميم الأولي يظل جزءاً لا غنى عنه، لكن بصيغة أخف وأكثر مرونة.
فبدل وثيقة ضخمة، يتم الاعتماد على كتابة وثائق حيّة “Living Documents” ونفصد بكلمة حيّه أنها وثيقة مُتجددة قابلة للتحديث المستمر مع كل دورة تطويرية وهي ما يصطلح على تسميته في منهجية Agile بإسم Sprint. أشهر أدوات تستخدمها فرق التطوير هي Confluence الذي يتكامل مع أداة JIRA الشهيرة وكذلك Draw.io لتوثيق القرارات التقنية بسرعة.
أما في بيئات DevOps، فيصبح التصميم الأولي جزءًا من التصميم المتطور المستمر (Continuous Design) الذي يتطور ويتراكم أثناء مراحل كتابة الكود نفسه.
متى يجب تحديث التصميم الأولي؟
كثير من الفرق تتعامل مع التصميم الأولي (High-Level Design) على أنه وثيقة تُكتب مرة واحدة في بداية المشروع ثم تُركن في الأرشيف، لكن في الواقع، التصميم الأولي وثيقة حية (Living Document) يجب أن تتطور مع تطور النظام.
يُفضّل تحديث التصميم الأولي في الحالات التالية:
- عند إدخال مكونات جديدة على النظام
مثل إضافة خدمة جديدة (New Microservice) أو طبقة تكامل (Integration Layer) مع نظام خارجي. - عند تغيير في المتطلبات الجوهرية
إذا تغيّرت المتطلبات الوظيفية (Functional Requirements) أو غير الوظيفية (Non-Functional Requirements) مثل الأداء أو الأمان. - عند ترحيل النظام إلى بيئة مختلفة
مثل الانتقال من خوادم داخلية (On-Premises) إلى بيئة سحابية (Cloud Environment) أو العكس يحدث أحياناً. - عند اكتشاف مشكلات معمارية أثناء التطوير
أحياناً يُظهر الواقع أن بعض القرارات التصميمية لم تكن مناسبة، وهنا يجب تعديل التصميم الأولي بدل الالتفاف حوله برمجياً. - عند دمج المنظمات أو الإدارات أو العكس بالتوسع المؤسسي مثل فصل المنظمة أو الإدارة لإدرات
مثل دمج نظامين تابعين لشركتين بعد استحواذ أو توسّع في الخدمات.
الحفاظ على تصميم أولي محدث يعني الحفاظ على وضوح رؤية الحل على المدى الطويل، ويُسهل عمليات المراجعة والتطوير المستقبلي دون ارتباك أو فقدان للمعرفة المؤسسية.
التصميم الأولي في سياق البنية المؤسسية الوطنية (NORA)
تُعد نورا (NORA) — National Enterprise Architecture Framework — الإطار الوطني للبنية المؤسسية الذي أصدرته هيئة الحكومة الرقمية بهدف توحيد منهجيات تصميم الأنظمة الحكومية وضمان تكاملها. هذا الإطار يحدد أربع طبقات رئيسية: طبقة الأعمال، وطبقة التطبيقات، وطبقة البيانات، وطبقة التقنية، وكل طبقة منها تمثل منظوراً مختلفاً من بنية الحلول الرقمية.
من هذا المنطلق، يُعتبر التصميم الأولي (High-Level Design) هو التطبيق العملي لمفاهيم نُورا على مستوى المشاريع التقنية. فهو يجسد كيف تتفاعل هذه الطبقات معاً داخل النظام المستهدف، ويحوّل المبادئ المعمارية إلى تصميم واقعي يمكن تنفيذه فعلياً.
عندما يلتزم مهندس الحلول بإطار نُورا أثناء إعداد التصميم الأولي، فهو لا يلتزم فقط بالحوكمة التقنية، بل يُسهم في تحقيق رؤية السعودية للتحول الرقمي التي تقوم على التكامل، وإعادة الاستخدام، ورفع كفاءة الأنظمة الحكومية والخاصة على حد سواء.
زبدة الكلام
التصميم الأولي (HLD) ليس مجرد مرحلة توثيق في دورة تطوير النظام، بل هو استثمار استراتيجي يُعبّر عن نضج التفكير الهندسي داخل أي منشأة تقنية. إنه الأداة التي تحفظ التوازن بين سرعة التنفيذ ودقّة المعمارية، وتحوّل الرؤية من فكرة غامضة إلى خطة تنفيذية واضحة يمكن البناء عليها بثقة.
في المشاريع التي تسعى للتحول الرقمي الجاد، يصبح التصميم الأولي انعكاساً لوعي القيادات التقنية بضرورة “التصميم قبل التنفيذ”، وتجسيداً عملياً لتوجهات الأطر الوطنية مثل نورا (NORA) التي تعزز التكامل والاتساق بين الأنظمة الحكومية والخاصة.
“حين تراجع وثيقة التصميم الأولي HLD في المرة القادمة، فاسأل نفسك: هل وثيقة التصميم الأولي التي كتبتها تروي فعلاً قصة النظام كاملة، بكل مكوناته وتفاعلاته؟”
في كثير من الأحيان، لا تحتاج المشاريع إلى إعادة البناء من الصفر، بل إلى عين خبيرة تعيد ترتيب الصورة من الأعلى، وتحوّل الفوضى التقنية إلى وضوح يمكن العمل عليه. وربما تبدأ هذه الخطوة ببساطة من مراجعة وثيقتك القادمة… لكن بعين من يفهم كيف تُبنى الحلول التي تعيش طويلاً.
