مقارنة
MapleSpire أم Structurizr: أيّهما يواكب الحوكمة على مستوى المؤسسات؟
يعتمد كلٌّ من Structurizr وMapleSpire على نموذج C4 وعلى نموذج حقيقي لا على رسومات. لكنهما يختلفان في مسألة حاسمة لأي مؤسسة كبيرة: أين توجد البيانات الوصفية المشتركة، ومن يستطيع إبقاءها محدّثة.
يتألق Structurizr حين تكون البنية المعمارية شيفرةً تكتبها فرق الهندسة وتراجعها في Git. أما MapleSpire فيستهدف مستودعًا خاضعًا للحوكمة: مجموعة واحدة من كتالوجات الوسوم والتقنيات للمؤسسة بأكملها، يحرّرها مرئيًا كل من يملك الصلاحية.
فلسفتان في النمذجة
Structurizr أداة من نوع «النماذج ككود»: تُكتب البنية المعمارية بلغة DSL نصية، وتُدار نسخها في Git، وتُرسَل إلى خادم يولّد المخططات. وتوصي وثائقه بمساحة عمل (workspace) واحدة لكل نظام برمجي، يملكها الفريق الذي يبنيه.
أما MapleSpire فنموذج مرئي مشترك: تعيش العناصر والعلاقات والعروض في قاعدة بيانات، ويُحرَّر بشكل جماعي في الوقت الفعلي، ويبقى متاحًا دون اتصال. وكتالوجات الوسوم والتقنيات كيانات على مستوى المؤسسة، لا نص يُنسخ في كل ملف.
لا يتفوّق أيّ من النهجين على الآخر بالمطلق. يظهر الفرق حين يزداد عدد الفرق والأنظمة والمساهمين.
إسناد البيانات الوصفية: الوسوم والتقنيات والإصدارات والمجموعات
| البيانات الوصفية | Structurizr | MapleSpire |
|---|---|---|
| الوسوم | نص حر لكل عنصر (tags «A,B»)؛ الأنماط مرتبطة بنص الوسم | وسوم ومجموعات وسوم تُعرَّف مرة واحدة للمؤسسة ويُشار إليها بمعرّف |
| إعادة تسمية وسم أو دمجه | بحث واستبدال في كل مساحة عمل | إعادة تسمية أو تغيير لون أو دمج أو أرشفة: تُطبَّق في كل مكان وفي جميع المشاهد المعمارية |
| التقنيات | نص حر (technology «Java») | كتالوج مُدار: أسماء بديلة وأيقونات فاتحة وداكنة وروابط إلى الوثائق |
| دورة حياة التقنية | غير منمذجة | نشطة أو متقادمة أو متوقفة أو مدمجة؛ والإدخالات الجديدة تمر بالموافقة |
| الإصدار المستخدم | تضيفه بنفسك في النص أو في properties | يُسجَّل الإصدار عند كل استخدام لتقنية |
| المجموعات والنطاقات | مجموعات مرئية تُعلَن في DSL | مجموعات يمكن أن تحمل وسومًا وتقنيات؛ ونطاقات هرمية |
| خصائص مخصّصة | properties وperspectives (أزواج مفتاح وقيمة حرة) | مخطَّط لها في النموذج، ولا يمكن تحريرها في الواجهة بعد |
في Structurizr يُوصَف العنصر بالكلمات المفتاحية tags وtechnology وproperties وperspectives. وهي نصوص حرة تُكتب عنصرًا عنصرًا. توفّر archetypes قيمًا افتراضية وترتبط الأنماط بالوسوم، لكن لا يوجد سجل مركزي يحدّد ما هو الوسم أو التقنية الصالحة.
عمليًا، قد تتعايش «PostgreSQL» و«Postgres» و«postgresql 16» في مساحات عمل مختلفة. وإعادة تسمية وسم تعني البحث والاستبدال في كل المستودعات المعنية، ولا شيء يمنع أحدًا من استخدام تقنية أوقفتها المؤسسة.
في MapleSpire لا يخزّن العنصر نص الوسم، بل مرجعًا إلى وسم مُعرَّف مرة واحدة للمؤسسة. وتأتي التقنيات من كتالوج مُدار يتضمن أسماء بديلة وأيقونات ودورة حياة.
وماذا عن المسؤولين؟
الملكية — أي الفريق المسؤول عن العنصر — كثيرًا ما تكون أول بيانات وصفية تطلبها عملية الحوكمة. في Structurizr تُكتب في خاصية حرة مثل المفتاح owner، دون أي صلة بدليل للفرق.
يدير MapleSpire الفرق أصلًا لأغراض التحكم في الوصول، ويتضمن نموذجه خطة لإسناد فرق مسؤولة إلى العناصر. غير أن هذا الإسناد غير متاح في الواجهة بعد: ونفضّل قول ذلك بوضوح على أن نَعِد به.
حدّث مرة واحدة، للجميع
للحصول على رؤية على مستوى المؤسسة، يقترح Structurizr نهجًا من ثلاث خطوات: جمع الأنظمة البرمجية في كتالوج DSL مشترك عبر رابط URL، وجعل مساحة عمل كل فريق توسّع هذا الكتالوج، ثم توليد مشهد معماري شامل. يُنتج هذا المشهدَ مسؤولٌ يسحب جميع مساحات العمل ويشغّل المولّد وينشر النتيجة. إنه نسخة: يجب إعادة توليدها لتعكس التغييرات اللاحقة.
في MapleSpire تعيش الوسوم والتقنيات في قاعدة بيانات المؤسسة. ويظهر أي تعديل في لوحة الإدارة فورًا في جميع المشاهد المعمارية، دون أي خطوة نشر. وداخل المشهد المعماري الواحد، يوجد كل عنصر مرة واحدة فقط ويشير إليه كل مخطط.
ملاحظتان توخيًا للدقة. في MapleSpire يبقى النموذج التفصيلي محصورًا في كل مشهد معماري، ولا يُشارَك على مستوى المؤسسة إلا الكتالوجات. كما يحتفظ كل استخدام لتقنية بمراجعة الكتالوج التي سُجّل بها، فلا يعيد أي تعديل على الكتالوج كتابة التاريخ بصمت.
التحكم في الوصول ومراجعة التغييرات
لا تتضمن النواة مفتوحة المصدر لـ Structurizr server مصادقةً ولا تحكمًا في الوصول قائمًا على الأدوار: مساحات العمل فيها عامة. أما الأدوار وSAML وLDAP وواجهة الإدارة البرمجية فتأتي مع الملفات التنفيذية الجاهزة المرخّصة. وقوّته الكبرى في مكان آخر: لأن النموذج شيفرة، يمكن أن يمر كل تغيير عبر طلب سحب (pull request) ومراجعة وتحقق آلي في التكامل المستمر.
تتضمن شيفرة MapleSpire المرخّصة بـ AGPL-3.0 أدوارًا على مستوى المؤسسة، وفرقًا بصلاحيات قراءة أو كتابة لكل مشهد معماري، وتسجيل دخول موحّدًا عبر OIDC مع Google أو Microsoft، وسجل تدقيق للإجراءات الإدارية. وتُحضَّر التغييرات في مسودات، مع قائمة بالتغييرات ودمج يكشف التعارضات.
القيد الحالي: لا تتضمن مسودات MapleSpire بعدُ خطوة موافقة رسمية قبل الدمج. فإذا كانت حوكمتك تشترط مراجعة إلزامية لكل تغيير، فإن مسار طلبات السحب في Structurizr أكثر صرامة اليوم.
أيّهما يتوسّع بشكل أفضل؟
| المعيار | Structurizr | MapleSpire |
|---|---|---|
| مفردات متّسقة بين الفرق | يعتمد على الانضباط والمراجعات | مفروضة عبر كتالوجات موحّدة |
| مساهمون من غير المطوّرين | عليهم تعلّم DSL وGit | تحرير مرئي متعدد المستخدمين في الوقت الفعلي |
| صورة شاملة محدّثة | يُعاد توليد المشهد عند الطلب | كتالوجات مشتركة مباشرة؛ ونموذج تفصيلي لكل مشهد |
| مراجعة إلزامية للتغييرات | طلبات السحب والتكامل المستمر | مسودات ودمج، دون موافقة رسمية حتى الآن |
| التحكم في الوصول وSSO | ملفات تنفيذية مرخّصة | مضمَّنة في الشيفرة مفتوحة المصدر |
| التوافر العالي | يعتمد على التخزين والترخيص المختارين | تعمل المزامنة حاليًا كنسخة واحدة |
إذا كان تحدّيك أن تتحدث المؤسسة كلها اللغة نفسها — الوسوم نفسها والتقنيات نفسها والإصدارات نفسها — وأن تُشرك المهندسين المعماريين ومسؤولي المنتجات والفرق التي لا تعمل في Git، فإن MapleSpire يتوسّع بشكل أفضل لأغراض الحوكمة.
أما إذا كانت بنيتك المعمارية تُدار أصلًا ككود، والمساهمون مطوّرون، والحوكمة تمر عبر مراجعة طلبات السحب، فإن Structurizr يبقى خيارًا ممتازًا.
الانتقال، أو استخدام الأداتين معًا
يستورد MapleSpire مساحة عمل Structurizr DSL وينشئ مخططات C4 المقابلة لها. كما يصدّر إلى Structurizr DSL وMermaid وJSON وCSV وSVG وPNG وMarkdown، لذا يمكنك تجربة MapleSpire على مساحة عمل قائمة دون التخلي عن ملفاتك.
المصادر
تستند المعلومات عن Structurizr إلى وثائقه الرسمية، التي جرى الاطلاع عليها في 12 أكتوبر 2026. وميزات MapleSpire الموصوفة هنا هي تلك الموجودة في الشيفرة المنشورة.