ما الفرق بين Manifest و Report و Finding؟ ماذا تعني مصطلحات التسلسل الهرمي للبيانات في هندسة البرمجيات؟ لماذا يتم تقسيم تصميم API إلى طبقات؟ وكيف تختلف Metadata و Artifact و Payload!

هل صادفت كثيرًا مصطلحات مثل Manifest و Report و Finding و Evidence أثناء قراءة وثائق API أو مخرجات أدوات الفحص الأمني أو سجلات CI/CD؟ هذه ليست بناءات لغوية خاصة بلغة برمجة معينة، بل هي مصطلحات التسلسل الهرمي للبيانات المتعارف عليها في الصناعة. فماذا تعني هذه المصطلحات حقًا؟

المفهوم الأساسي: فهم التسلسل الهرمي للبيانات من خلال “الفحص الطبي”

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

المصطلح	تشبيه الفحص الطبي	الشرح المقابل في هندسة البرمجيات
`Manifest`	استمارة التسجيل للفحص	تعلن عن العناصر المراد تنفيذها والإصدارات وإعدادات البيئة؛ وهي بيانات وصفية.
`Report`	تقرير الفحص الطبي الكامل	ملخص كامل بعد انتهاء التنفيذ، يشمل الحالة العامة ونتائج التدقيق.
`Finding`	الملاحظات المحددة بالأحمر في التقرير	اكتشاف محدد تم تحديده في التقرير، مثل “ارتفاع ضغط الدم” أو ثغرة أمنية.
`Evidence`	شريط بيانات جهاز قياس الضغط	أدلة خام موضوعية تدعم الاكتشاف، مثل سجلات النظام (Log) أو قياسات البيانات.

هذه المصطلحات ليست كلمات محجوزة في لغات البرمجة، بل هي نماذج بيانات مشتركة متعارف عليها في الصناعة.

يمكننا استخدام مخطط Mermaid لتوضيح العلاقات الهيكلية والاحتواء بين هذه العناصر الأربعة في بنية البيانات:

  graph TD
    A["Manifest (مواصفات التنفيذ/البيانات الوصفية)"] -->|تحدد النطاق والتنفيذ| B["Report (تقرير الملخص الكامل)"]
    B -->|يتضمن متعدد| C["Finding (اكتشاف محدد/ملاحظة)"]
    C -->|يرتبط بمتعدد| D["Evidence (دليل خام موضوعي)"]

لماذا يتم التصميم بهذه الطبقات؟ المزايا الثلاث الكبرى للتسلسل الهرمي للبيانات

لماذا يقسم النظام البيانات بشكل تفصيلي بدلاً من حشوها بالكامل في كائن JSON ضخم واحد؟ يقدم هذا التصميم عدة مزايا رئيسية:

تصميم هندسة API الممتاز يجعل تحميل الواجهة الأمامية أكثر سلاسة، ويزيد من موثوقية البيانات وقابليتها للتوسع.

الميزة	الشرح
فصل المسؤوليات (Separation of Concerns)	يمكن للواجهة الأمامية تحميل ملخص `Finding` أولاً لعرضه سريعًا للمستخدم، واستدعاء بيانات `Evidence` الضخمة فقط عند الحاجة إلى التعمق.
موثوقية عالية	يوفر تقديم `Evidence` إثباتًا على أن `Finding` ليس إنذارًا كاذبًا، مما يزيد بشكل كبير من قابلية النظام للتدقيق.
توسع مرن	يمكن ربط `Finding` واحد بمرونة مع عدة عناصر `Evidence` دون كسر صيغة البيانات الأصلية.

مصطلحات شائعة أخرى مكملة: Metadata و Artifact و Payload

بالإضافة إلى الطبقات الأربع الأساسية المذكورة أعلاه، عند تصميم API أو بناء خطوط الأنابيب (Pipelines) أو تحديد صيغ النقل، ستصادف بالتأكيد هذه المصطلحات الثلاثة: Metadata و Artifact و Payload:

المصطلح	التعريف الأساسي	التشبيه من الحياة اليومية	مثال التطبيق العملي في هندسة البرمجيات
`Metadata`	بيانات تصف البيانات نفسها	ملصق الشحن الخارجي للطرد، معلومات صورة EXIF	`HTTP Header`، الطابع الزمني للطلب `timestamp`، معلومات الترقيم `page`.
`Artifact`	مخرجات مادية ملموسة ناتجة بعد تنفيذ العملية	سيارة مصنعة في مصنع، قرص مدمج للفحص الطبي	ملف `.apk` مجمع، صورة `Docker Image`، تقرير تدقيق `PDF`.
`Payload`	البيانات التجارية الأساسية المراد نقلها حقًا	الهاتف الذكي الموجود فعليًا داخل صندوق الطرد	المحتوى التجاري الأساسي `JSON` داخل `HTTP POST Body`.

Payload يشبه الأغراض الموجودة داخل طرد البريد، بينما Metadata هي ملصق الشحن الملصق على الجزء الخارجي من الطرد.

ولفهم كيفية عمل هذه العناصر الثلاثة معًا بشكل أوضح، يمكننا ملاحظة بنية بيانات طلب API Request نموذجية:

{
  "metadata": {
    "version": "v1.2.0",
    "timestamp": "2026-08-02T15:08:41Z",
    "request_id": "req-98765"
  },
  "payload": {
    "report_id": "REP-2026-001",
    "status": "COMPLETED",
    "artifact_url": "https://example.com/artifacts/build-report.pdf"
  }
}

في مثال JSON هذا:

توفر metadata سياق النقل والبيئة (الإصدار، الطابع الزمني، معرف الطلب).
تحتوي payload على بيانات منطق العمل الفعلية المنقولة (معرف التقرير، الحالة).
يشير artifact_url إلى الملف المادي الفعلي الناتج عن مهمة البناء هذه (Artifact).

قوة المفردات المشتركة: جسر التواصل بين الأنظمة المختلفة

عندما تعتمد أدوات وفرق مختلفة نموذج البيانات المماثل هذا (مثل Report -> Findings -> Evidence)، ستنخفض تكلفة التواصل بين الفرق بشكل كبير.

تخيل أن الـ Report الناتج عن أداة CI/CD الخاصة بك يمكن نقله مباشرة وبدون أي عوائق إلى النظام الأمني للتحليل — هذه هي قوة التكامل التي تمنحها لغة المجال المشتركة.

  sequenceDiagram
    autonumber
    actor CI as CI/CD Pipeline
    participant Scanner as الفاحص الأمني
    participant Dashboard as لوحة التحكم والإدارة
    
    CI->>Scanner: تقديم Manifest لتنفيذ الفحص
    Scanner->>Scanner: إنشاء Report و Findings
    Scanner->>Dashboard: إرسال Payload المهيكل (Finding + Evidence)
    Dashboard-->>CI: عرض نتائج التدقيق

الخلاصة

في الحقيقة، الهدف الأساسي لهذه المصطلحات هو حل مشكلات التواصل وتنسيق البيانات بين الأنظمة البرمجية كبيرة الحجم.

عند ربط الأنظمة أو تصميم API، حاول دمج مفاهيم التسلسل الهرمي للبيانات هذه في بنية Payload الخاصة بك، مما يجعل تصميم نظامك أكثر احترافية وقابلية للتوسع!