التصميم والمعمارية: أربعة مستويات لنشاط واحد

افتح أي موقع للوظائف التقنية وسوف تجد في نفس اليوم إعلاناً يطلب «مهندس برمجيات يجيد تصميم البرمجيات Software Design»، وآخر يطلب «معماري برمجيات Software Architect»، وثالثاً يطلب خبرة في «تصميم الأنظمة System Design»، ثم تأتيك كراسة شروط من جهة حكومية تطلب أن يتوافق النظام مع «معمارية المؤسسة Enterprise Architecture»، وعندما تسأل الفريق عن الفرق بين هذه الكلمات الأربع تسمع إجابات مختلفة، فمنهم من يراها أسماء متعددة لشيء واحد، ومنهم من يرى أن المعمارية مجرد رسومات يرسمها شخص لا يكتب الكود، والسبب في هذا الخلط أن الكلمات الأربع تصف نفس النشاط، أي اتخاذ قرارات عن شكل البرنامج قبل أن يصعب تغييره، ولكن كل كلمة تنظر إليه من مسافة مختلفة.

وهذا المقال هو مدخل مرحلة «معمارية البرمجيات وتصميمها» في خارطة الطريق، فهو يضع الصورة الكاملة ثم يرسلك إلى المقال المختص بكل جزء، وسوف نناقش في هذا المقال ما يلي:

• الفكرة التي تجمع المصطلحات الأربعة: مستويات من التكبير Zoom Levels، من سطر الكود إلى المؤسسة كلها.
• ما هو تصميم البرمجيات Software Design، والمشكلة التي يحلها، ومن يحتاجه.
• ما هي معمارية البرمجيات Software Architecture بتعريفات من المعيار ISO/IEC/IEEE 42010 ومعهد هندسة البرمجيات SEI وMartin Fowler، وأين ينتهي التصميم وتبدأ المعمارية.
• ما هو تصميم الأنظمة System Design، ولماذا يتداخل مع المعمارية.
• ما هي معمارية المؤسسة Enterprise Architecture، ولماذا تحتاجها المؤسسات الكبيرة والجهات الحكومية.
• من يقرر في كل مستوى، وكم يعيش القرار، وقانون Conway الذي يربط شكل النظام بشكل الفريق.
• خصائص الجودة Quality Attributes التي تحميها المعمارية، وكيف تكتبها بالأرقام، ولماذا تتنافس فيما بينها.
• مسار القراءة في المرحلة: أي مقال تقرأ بعد هذا، ولماذا.

الفكرة الأساسية: أربعة مستويات من التكبير Zoom Levels

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

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

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

تصميم البرمجيات Software Design: ترتيب الكود داخل الميزة

تصميم البرمجيات هو القرارات التي تتخذها داخل جزء واحد من البرنامج: كيف تقسم الكود إلى كلاسات Classes ودوال Functions ووحدات Modules، وما الواجهة Interface التي يعرضها كل جزء لغيره، ومن يعتمد على من. وهذه القرارات تأخذ دقائق أو ساعات، ويمكن تغييرها في مراجعة الكود Code Review أو في إعادة الهيكلة Refactoring دون أن يشعر المستخدم بشيء.

لنأخذ مثالاً: ميزة تصدر فاتورة وتحسب الضريبة وترسلها بالبريد. الحل البسيط أن تكتب كل ذلك في دالة واحدة داخل ال Controller، فهي تقرأ الطلب من قاعدة البيانات وتحسب الضريبة بنسبة مكتوبة في الكود وتبني نص البريد وترسله، وهذا يعمل في الأسبوع الأول، ولكن المشكلة تظهر عندما تتغير نسبة الضريبة أو يضاف نوع جديد من العملاء أو يطلب منك أن ترسل الفاتورة عبر WhatsApp بدل البريد، فتجد نفسك تعدل نفس الدالة الطويلة في كل مرة، وتكسر شيئاً لم تقصده، ولا تستطيع أن تختبر حساب الضريبة وحده لأنه مربوط بقاعدة البيانات وخادم البريد. أما التصميم الأفضل فيفصل حساب الضريبة في جزء له مسؤولية واحدة، ويجعل طريقة الإرسال قابلة للتبديل، ويجعل منطق الفاتورة لا يعرف شيئاً عن قاعدة البيانات، وهذا بالضبط ما تشرحه مبادئ التصميم وأنماطه في المقالين التاليين من المرحلة.

والمشكلة التي يحلها التصميم هي كلفة التعديل وليس سرعة البداية، ويشرح Martin Fowler ذلك في مقاله Design Stamina Hypothesis، حيث يقول إن المشروع الذي لا يهتم بالتصميم يسلم الميزات أسرع في البداية، ثم يبطئ مع الوقت حتى يتجاوزه المشروع الذي اهتم بالتصميم، والسبب ما يسمى الدين التقني Technical Debt، وهو تشبيه وضعه Ward Cunningham كما يذكر Fowler في صفحة Technical Debt: كل اختصار تأخذه اليوم يصبح ديناً، والجهد الإضافي الذي تبذله في كل ميزة جديدة بسبب الكود المتشابك هو الفائدة التي تدفعها على هذا الدين.

ومن يحتاج تصميم البرمجيات؟ كل مطور يكتب كوداً سيعدله شخص آخر، أو سيعدله هو بعد ستة أشهر وقد نسي لماذا كتبه بهذا الشكل، فلا يوجد مشروع صغير إلى درجة أنه لا يحتاج تصميماً، ولكن يوجد مشروع صغير إلى درجة أنه لا يحتاج كل الأنماط التي قرأت عنها، وهذا ما نناقشه في مبدأ YAGNI وفي حديثنا عن أنماط التصميم ومتى تصبح تعقيداً زائداً. وإذا أردت أن تراجع معنى الكلاس والوراثة Inheritance قبل ذلك، فقد شرحناها في قسم البرمجة الكائنية OOP.

معمارية البرمجيات Software Architecture: القرارات التي يصعب تغييرها

عندما تبتعد خطوة عن الكود تبدأ في رؤية قرارات من نوع آخر: هل التطبيق برنامج واحد أم عدة خدمات؟ هل تتكلم الأجزاء مع بعضها باستدعاء مباشر أم برسائل عبر طابور Queue؟ ما قاعدة البيانات، وهل يملك كل جزء بياناته؟ كيف يعتمد جزء الطلبات على جزء الفواتير؟ وهذه القرارات لا يمكن تغييرها في مراجعة كود واحدة، فبعضها يكلف أسابيع وبعضها يكلف إعادة كتابة.

ويعرف المعيار الدولي ISO/IEC/IEEE 42010 المعمارية كما في صفحة تعريف المعمارية على موقع المعيار بأنها «المفاهيم أو الخصائص الأساسية للنظام في بيئته، المتجسدة في عناصره وعلاقاته ومبادئ تصميمه وتطوره»، ويشرح الموقع أن المعمارية هي ما هو أساسي في النظام وليس كل شيء فيه. أما معهد هندسة البرمجيات SEI في جامعة Carnegie Mellon فيقول في صفحة Software Architecture إن معمارية النظام تمثل قرارات التصميم المتعلقة ببنيته وسلوكه العام، وإنها تساعد أصحاب المصلحة Stakeholders على فهم كيف سيحقق النظام خصائص أساسية مثل قابلية التعديل Modifiability والتوافرية Availability والأمن Security، وإنها تسمح بتحليل هذه الخصائص أثناء اتخاذ القرار وليس بعد التنفيذ والنشر. ويظهر استقلال المعمارية عن التصميم كمجال في الدليل المعرفي لهندسة البرمجيات SWEBOK الذي تصدره جمعية IEEE Computer Society، فقد أضاف إصداره الرابع SWEBOK V4.0 معمارية البرمجيات كمجال معرفي جديد Knowledge Area مستقل، مع مجالين جديدين آخرين هما عمليات هندسة البرمجيات والأمن.

والتعريف الذي يستخدمه أغلب المطورين في عملهم جاء من نقاش بين Martin Fowler وRalph Johnson نشره Fowler في مقاله Who Needs an Architect? في مجلة IEEE Software عام 2003، ثم لخصه في دليله عن معمارية البرمجيات. فقد اعترض Johnson على تعريف المعمارية بأنها «القرارات التي يجب اتخاذها مبكراً في المشروع» وقال إنها في الحقيقة القرارات التي تتمنى لو اتخذتها بشكل صحيح مبكراً، وإنه لا توجد طريقة موضوعية لتحديد ما هو «أساسي»، وانتهى إلى أن «المعمارية هي الأشياء المهمة، أياً كانت». ويضيف Fowler في نفس المقال أن الناس يريدون اتخاذ بعض القرارات مبكراً لأنهم يرونها صعبة التغيير، لذلك يمكن تعريف المعمارية بأنها «الأشياء التي يرى الناس أنها صعبة التغيير».

وقد يتساءل البعض: إذا كانت المعمارية «الأشياء المهمة» فقط، فكيف أعرف ما المهم في مشروعي؟ والإجابة أن المهم هو ما يكلفك كثيراً إذا أخطأت فيه، فاختيار اسم متغير ليس مهماً لأنك تغيره في ثانية، أما اختيار أن يملك كل جزء قاعدة بياناته المنفصلة فهو مهم لأن الرجوع عنه يعني نقل بيانات ودمج جداول وتغيير طريقة النشر.

أين ينتهي التصميم وتبدأ المعمارية؟

يذكر موقع المعيار 42010 في نفس الصفحة فرقاً يتكرر كثيراً بين المعمارية والتصميم: المعمارية تنظر إلى الخارج، إلى النظام داخل بيئته، أما التصميم فينظر إلى الداخل بعد أن تتحدد حدود النظام. والبيئة هنا تعني كل ما يؤثر في النظام: المستخدمون وعددهم، والأنظمة الخارجية التي يتصل بها مثل بوابة الدفع، والجهات التنظيمية وما تطلبه، والفريق وميزانيته. والصورة التالية تبين الاتجاهين، وتحتهما مقياس كلفة التغيير الذي يحسم أغلب النقاشات:

في الصورة أعلاه لاحظ التالي:

• إعادة تسمية متغير أو تقسيم كلاس قرارات تصميم، لأنك تغيرها في نفس اليوم دون أن يتأثر أي شيء خارج الكود.
• حدود الوحدات Module Boundaries في المنتصف، فهي تبدأ قرار تصميم في مشروع صغير وتصبح قراراً معمارياً عندما تعمل عليها عدة فرق، والسبب أن تغييرها يحتاج تنسيقاً بين أشخاص وليس تعديل كود فقط.
• تغيير قاعدة البيانات أو الانتقال من برنامج واحد Monolith إلى خدمات Microservices قرارات معمارية واضحة، لأن الرجوع عنها يكلف أشهراً.

وبهذا الشكل يصبح السؤال العملي في أي نقاش هو «كم سيكلفنا تغيير هذا القرار بعد سنة؟»، فإذا كانت الإجابة «ساعة» فلا تضيع اجتماعاً عليه، وإذا كانت «ربع سنة» فاكتب القرار وأسبابه في سجل القرارات المعمارية ADR الذي نشرحه في مقال توثيق المعمارية.

أمثلة على قرارات معمارية حقيقية

وحتى لا تبقى الفكرة نظرية، فهذه قرارات تقابلها في أغلب المشاريع، وكلها تصنف معمارية لأنها صعبة التغيير وتؤثر في أكثر من جزء:

• شكل النشر Deployment: برنامج واحد، أم برنامج واحد مقسم إلى وحدات Modular Monolith، أم خدمات منفصلة. والفروق بينها في مقال أنماط المعمارية.
• اتجاه الاعتماديات Dependencies: هل يعتمد منطق العمل على قاعدة البيانات، أم تعتمد قاعدة البيانات على منطق العمل؟ وهذا موضوع مقال Clean Architecture.
• طريقة الاتصال Communication: استدعاء متزامن Synchronous عبر HTTP، أم رسائل غير متزامنة Asynchronous عبر طابور، وما يعنيه ذلك عند تعطل جزء.
• ملكية البيانات Data Ownership: قاعدة بيانات واحدة يقرأ منها الجميع، أم قاعدة لكل جزء.
• عزل العملاء Tenant Isolation في تطبيقات SaaS، وقد شرحنا نماذجه في مقال تعدد المستأجرين Multi-Tenancy.
• توزيع الأجزاء على الشبكة: كم مستوى Tier يفصل الإنترنت عن قاعدة البيانات، وهو موضوع مقال الفرق بين Tiers وLayers.

من هو المعماري Architect؟

في نفس مقال Who Needs an Architect? يصف Fowler نوعين من المعماريين: الأول يسميه Architectus Reloadus، وهو الشخص الذي يتخذ كل القرارات المهمة وحده لأنه يرى أن النظام يحتاج عقلاً واحداً يضمن تماسكه، والثاني يسميه Architectus Oryzus، وهو عضو في الفريق يعمل مع المطورين ويكتب الكود معهم ويرفع مستوى الفريق حتى يستطيع التعامل مع المشكلات الصعبة. ويقول Fowler في نفس المقال إن من أهم مهام المعماري أن يزيل المعمارية، أي أن يجد طرقاً تقلل القرارات التي لا رجوع عنها Irreversibility في التصميم.

والخلاصة العملية أن المعمارية دور قبل أن تكون مسمى وظيفياً: في فريق من ثلاثة مطورين يقوم بهذا الدور أكثرهم خبرة أو قائد الفريق Tech Lead، وفي شركة فيها عشرة فرق قد يوجد معماري متفرغ، وفي الحالتين لا ينصح بأن يكون المعماري شخصاً يرسم المخططات ثم يغادر، والسبب أن المعمارية كما وصفها Johnson هي «فهم مشترك» عند الخبراء في الفريق، والفهم المشترك لا يصنعه شخص لا يعمل مع الفريق.

تصميم الأنظمة System Design: كيف تعمل الأجزاء معاً تحت الحمل

إذا ابتعدت خطوة أخرى فلن ترى الكلاسات ولا الوحدات، وإنما ترى صناديق تعمل في التشغيل: موزع الحمل Load Balancer، ونسخ التطبيق، والتخزين المؤقت Cache، وقاعدة البيانات ونسختها المتماثلة Replica، والطابور والعامل Worker الذي يعالج الرسائل، والتخزين الكائني Object Storage للملفات، والمراقبة Monitoring. وتصميم الأنظمة هو ترتيب هذه الصناديق بحيث يتحمل النظام عدد المستخدمين المطلوب ويبقى يعمل عند تعطل جزء منه، ويكون زمن الاستجابة Latency مقبولاً، والكلفة معقولة.

والصورة التالية تبين نظاماً من هذا النوع، والأسئلة المرقمة فيها هي الأسئلة التي يبدأ بها أي تصميم أنظمة:

ومصطلح System Design بهذا المعنى منتشر في صناعة البرمجيات وفي مقابلات العمل أكثر منه في المعايير، ومن أشهر المراجع المفتوحة له مستودع The System Design Primer الذي يصف هدفه بأنه تعلم تصميم الأنظمة الكبيرة والاستعداد لمقابلات تصميم الأنظمة. أما موقع المعيار 42010 فيذكر في صفحة التعريف أن معمارية الأنظمة System Architecture تركز على بنية الأنظمة الفرعية وعلاقات مثل التوزيع Allocation، أي أين يعمل كل جزء، وهذا قريب جداً مما يقصده المطورون بتصميم الأنظمة.

وقد يتساءل البعض: هل تصميم الأنظمة جزء من معمارية البرمجيات أم شيء آخر؟ والإجابة أنهما متداخلان، فمعمارية البرمجيات تشمل البنية الداخلية للتطبيق وطريقة تشغيله معاً، وتصميم الأنظمة يركز على جانب التشغيل والتوسع Scalability والاعتمادية Reliability، لذلك قد تسمع المعماري يناقش اتجاه الاعتماديات بين الوحدات في الصباح، ثم يناقش عدد النسخ خلف موزع الحمل بعد الظهر، وكلاهما عمل معماري، ولكن مقابلة «System Design» في الشركات تسأل عن الثاني غالباً.

ولن نكرر هنا تفاصيل هذا المستوى لأن لها مرحلة كاملة في خارطة الطريق: الخطوات من سيرفر واحد إلى ملايين المستخدمين في مدخل إلى تصميم الأنظمة، والنسخ المتماثل Replication والإجماع Consensus في الأنظمة الموزعة للمبتدئين، والفصل بين المستويات في الشبكة في مقال Tiers وLayers.

معمارية المؤسسة Enterprise Architecture: الصورة فوق كل الأنظمة

المستوى الأخير لا ينظر إلى نظام واحد أصلاً، فالمؤسسة الكبيرة تملك عشرات أو مئات الأنظمة: نظام تخطيط موارد ERP، ونظام موارد بشرية HR، ونظام إدارة علاقات العملاء CRM، وبوابة للعملاء، وتقارير، وجداول Excel تعمل كأنظمة دون أن يسميها أحد بذلك، وكل منها اشترته أو بنته إدارة مختلفة في سنة مختلفة بميزانية مختلفة. ويصف Fowler هذا الفرق في دليله عن المعمارية، فمعمارية التطبيق تعمل داخل حدود تطبيق له هدف واحد، أما معمارية المؤسسة فتنظر عبر مؤسسة كبيرة فيها فرق كثيرة وقواعد كود تطورت منفصلة عن بعضها، وميزانيات ومستخدمون مستقلون، ويقول إن جزءاً كبيراً من عملها هو فهم ما يستحق كلفة التنسيق المركزي وما الشكل الذي يأخذه هذا التنسيق.

والحل البسيط في المؤسسات هو أن تشتري كل إدارة ما يناسبها، وهذا سريع في البداية، ولكن بعد سنوات تجد نظامين لإدارة العملاء لا يتفقان على عدد العملاء، وتقارير مالية تجمع يدوياً من ثلاثة مصادر، وروابط بين الأنظمة كتبها كل فريق بطريقته فلا يعرف أحد ماذا ينكسر إذا أوقف نظاماً قديماً. والحل المعاكس، أي مجموعة مركزية توافق على كل قرار في كل نظام، يبطئ الجميع، ويذكر Fowler أن هذه المجموعات لا تستطيع أن تفهم مشكلات هذا العدد الكبير من الأنظمة فتصدر قرارات سيئة. ومعمارية المؤسسة تبحث عن الطريق بينهما. والصورة التالية تبين الفرق:

ويذكر موقع المعيار 42010 أن معمارية المؤسسة تركز على المبادئ Principles أكثر من التفاصيل، وهذا واضح في مخرجاتها: مبادئ ومعايير تتبعها كل الأنظمة، وخريطة قدرات الأعمال Business Capability Map التي تصف ما تفعله المؤسسة بغض النظر عن الأنظمة، ومحفظة التطبيقات Application Portfolio التي تقرر أي نظام يبقى وأي نظام يدمج أو يستبدل، وخارطة طريق Roadmap للانتقال. ومن أشهر الأطر Frameworks في هذا المجال معيار TOGAF من The Open Group، والذي تصفه المنظمة بأنه منهجية وإطار لمعمارية المؤسسة، وأحدث إصداراته الطبعة العاشرة.

ومن يحتاج معمارية المؤسسة؟ المؤسسات الكبيرة والجهات الحكومية التي تملك أنظمة كثيرة وتحتاج أن تعرف ما تملكه قبل أن تشتري المزيد، أما شركة ناشئة فيها نظام واحد وعشرة موظفين فلا تحتاجها، وتكفيها معمارية تطبيق جيدة. وقد خصصنا لهذا المستوى ثلاثة مقالات في نفس المرحلة: المشكلة التي تحلها معمارية المؤسسة مع TOGAF وZachman، وخريطة القدرات ومحفظة التطبيقات، ومعمارية المؤسسة في الجهات الحكومية:

دليلمعمارية المؤسسة Enterprise Architecture ببساطةعندما تملك المؤسسة عشرات الأنظمة لا يعرف أحد ماذا يتوقف إذا أوقفت أحدها، وهنا يأتي دور معمارية المؤسسة وأطرها المعروفة.دليلCapability Map: كيف تقرر مصير كل نظام في مؤسستككيف تبني خريطة لقدرات مؤسستك وتربط بها أنظمتك، لتكتشف التكرار والفجوات وتقرر ما تبقيه وما توقفه.دليلمعمارية المؤسسة EA في الجهات الحكومية السعوديةما الذي تطلبه هيئة الحكومة الرقمية من الجهات في البنية المؤسسية بالنص، وكيف يقاس، وأين يلتقي مع ضوابط الأمن السيبراني.

كيف ترتبط المستويات الأربعة ببعضها؟

بعد أن رأينا كل مستوى وحده، فالجدول التالي يضعها بجانب بعضها حتى ترى الفرق في سطر واحد:

لاحظ أن كل مستوى يضع حدوداً للمستوى الذي تحته: معمارية المؤسسة تقرر مثلاً أن كل الأنظمة تستخدم الدخول الموحد SSO، فيأخذ معماري التطبيق هذا القرار كقيد، ثم يختار المطور طريقة كتابة الكود التي تتعامل معه، وفي الاتجاه المعاكس تصعد المعلومات من الأسفل، فإذا اكتشف الفريق أن قيداً مؤسسياً يجعل النظام بطيئاً فعليه أن يرفع ذلك إلى المستوى الأعلى بدل أن يلتف عليه بصمت.

من يقرر، وكم يعيش القرار؟

الصورة التالية تضع أمثلة من القرارات على محور الزمن، من إعادة تسمية دالة إلى استبدال نظام ERP، ومع كل قرار من يتخذه في الغالب:

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

قانون Conway: النظام يشبه الفرق التي بنته

في عام 1968 نشر Melvin Conway في مجلة Datamation ورقة بعنوان How Do Committees Invent?، وفكرتها كما يلخصها هو في صفحته عن القانون أن أي مؤسسة تصمم نظاماً سوف تنتج تصميماً يطابق بنية الاتصال داخل المؤسسة، وقد سماه Fred Brooks لاحقاً «قانون Conway» في كتابه The Mythical Man-Month فبقي الاسم. ومعنى ذلك في الواقع أنك إذا قسمت الفريق إلى فريق واجهات وفريق خلفية وفريق قواعد بيانات، فسوف تحصل على نظام من ثلاث طبقات أفقية، وكل ميزة صغيرة تحتاج تنسيقاً بين الفرق الثلاثة، أما إذا قسمته حسب مجالات العمل مثل الطلبات والفواتير والكتالوج فسوف تحصل على أجزاء رأسية يملك كل فريق أحدها من الواجهة إلى قاعدة البيانات:

ويذكر Fowler في صفحة Conway's Law أن بعض الفرق تستخدم القانون في الاتجاه المعاكس، فتغير تقسيم الفرق أولاً لتحصل على المعمارية التي تريدها، وهذا ما يسمى المناورة العكسية Inverse Conway Maneuver، وهو سبب من أسباب تقسيم الفرق حول قدرات الأعمال في الشركات التي تعمل بالخدمات المصغرة. وهذا يعني أن المعمارية ليست قراراً تقنياً فقط، فإذا رسمت خدمات منفصلة لفريق واحد من أربعة أشخاص فأنت تصمم نظاماً لا يشبه الفريق الذي سيبنيه، وسوف يدفع الفريق ثمن ذلك في كل نشر.

خصائص الجودة Quality Attributes: ما الذي تحميه المعمارية فعلاً؟

المتطلبات نوعان: متطلبات وظيفية Functional Requirements تقول ماذا يفعل النظام، مثل «يصدر المستخدم فاتورة»، ومتطلبات غير وظيفية Non-functional Requirements تقول كيف يجب أن يفعله، مثل «خلال أقل من ثانية» و«حتى لو توقف سيرفر» و«دون أن يرى عميل فاتورة عميل آخر». ويمكنك أن تحقق المتطلبات الوظيفية بأي معمارية تقريباً، فالفاتورة تصدر من برنامج مرتب ومن برنامج متشابك، أما المتطلبات غير الوظيفية فهي التي تحدد المعمارية، لذلك تسمى أيضاً خصائص الجودة Quality Attributes أو الخصائص المعمارية Architecture Characteristics، وهذا ما يقصده SEI عندما يقول إن المعمارية تساعد على فهم كيف سيحقق النظام خصائص مثل قابلية التعديل والتوافرية والأمن.

وأشهر قائمة معيارية لهذه الخصائص هي نموذج جودة المنتج في المعيار ISO/IEC 25010، وإصداره الحالي من عام 2023 فيه تسع خصائص كما يشرحها موقع ISO 25000:

• الملاءمة الوظيفية Functional Suitability: هل يقدم النظام الوظائف المطلوبة كاملة وصحيحة؟
• كفاءة الأداء Performance Efficiency: زمن الاستجابة والإنتاجية Throughput واستهلاك الموارد والسعة Capacity.
• التوافق Compatibility: هل يعمل مع أنظمة أخرى ويتبادل معها البيانات Interoperability؟
• قابلية التفاعل Interaction Capability: سهولة التعلم والاستخدام والحماية من أخطاء المستخدم والشمولية Inclusivity.
• الاعتمادية Reliability: وتشمل التوافرية Availability وتحمل الأعطال Fault Tolerance والقدرة على التعافي Recoverability.
• الأمن Security: حماية البيانات من الوصول والتعديل غير المصرح به.
• قابلية الصيانة Maintainability: سهولة فهم الكود وتعديله واختباره.
• المرونة Flexibility: قدرة النظام على التكيف مع متطلبات أو بيئات جديدة، ومنها قابلية التوسع Scalability.
• السلامة Safety: ألا يعرض النظام حياة الناس أو صحتهم أو ممتلكاتهم أو البيئة للخطر، وهي مهمة جداً في الأنظمة الطبية والصناعية.

ومزودو السحابة لديهم نسختهم من نفس الفكرة: Microsoft تقسم إطار Azure Well-Architected إلى خمس ركائز Pillars هي الاعتمادية والأمن وتحسين الكلفة Cost Optimization والتميز التشغيلي Operational Excellence وكفاءة الأداء، وAWS تذكر في إطار Well-Architected ست ركائز تضيف إليها الاستدامة Sustainability. ولاحظ أن الكلفة تظهر عند مزودي السحابة كخاصية معمارية صريحة، وهذا منطقي لأن قرار التوزيع على ثلاث مناطق Regions مثلاً يضاعف الفاتورة.

اكتب الخاصية برقم وليس بكلمة

كلمة «سريع» أو «متاح دائماً» لا تساعد المعماري في اتخاذ أي قرار، والسبب أن كل شخص يفهمها بطريقة مختلفة، لذلك حول كل خاصية إلى جملة يمكن قياسها: بدل «النظام متاح دائماً» اكتب «التوافرية 99.9% شهرياً»، وهذا يعني أن التوقف المسموح في شهر من 30 يوماً هو 0.1% من 43200 دقيقة، أي 43.2 دقيقة تقريباً، وعندها يصبح السؤال واضحاً: هل يكفي سيرفر واحد مع نسخة احتياطية تستعاد في عشرين دقيقة، أم تحتاج نسختين خلف موزع حمل؟ وبدل «سريع» اكتب جملة فيها زمن ونسبة وحمل، مثل «95% من طلبات صفحة الطلبات تنتهي في أقل من 300 ملي ثانية عند 200 طلب في الثانية»، والأرقام هنا للتوضيح فقط، وأرقام نظامك تأتي من المستخدمين ومن قياس النظام الحالي. وبدل «آمن» اكتب التهديدات التي يجب أن يصمد أمامها، وقد شرحنا طريقة استخراجها في نمذجة التهديدات Threat Modeling.

لماذا تتنافس الخصائص فيما بينها؟

لا يوجد نظام يأخذ أعلى درجة في كل الخصائص، فكل خاصية تحسنها تأخذ من خاصية أخرى، والصورة التالية تبين أشهر حالات التوازن Trade-offs التي ستقابلها:

• الأمن مقابل الأداء: كل طبقة تشفير وفحص وتسجيل تضيف وقتاً إلى الطلب، ولا يعني ذلك أن تحذفها، وإنما أن تحسب أثرها وتضعها في المكان الصحيح.
• التوافرية مقابل الكلفة: نسخة ثانية في موقع آخر ترفع التوافرية وتضاعف عدد السيرفرات وكلفة نقل البيانات.
• الاتساق Consistency مقابل التوافرية: عندما تنقطع الشبكة بين نسخ قاعدة البيانات يجب أن تختار بين رفض الطلب أو قبوله ببيانات قد تكون قديمة، وهذا ما تقوله نظرية CAP.
• المرونة مقابل البساطة: كل نقطة توسيع تضيفها «للمستقبل» كود إضافي يجب أن يفهمه الفريق ويختبره، وكثير منها لا يستخدم أبداً، وهذا ما يحذر منه مبدأ YAGNI.

ولأن هذه الموازنة هي قلب العمل المعماري، فقد طور SEI طريقة كاملة لتقييمها اسمها Architecture Tradeoff Analysis Method واختصاراً ATAM، وهي تقيم المعمارية مقابل أهداف خصائص الجودة وتكشف المخاطر وكيف تؤثر الخصائص في بعضها، وقد لا تحتاج تطبيقها كاملة في مشروع صغير، ولكن فكرتها تنفعك في أي اجتماع: لا تسأل «هل هذا التصميم جيد؟» وإنما اسأل «جيد في ماذا، وعلى حساب ماذا؟».

اختر القليل الذي يهمك

الخطأ الشائع أن يكتب الفريق كل الخصائص التسع في وثيقة المتطلبات ويصفها كلها بأنها «عالية»، وهذا يعني في الواقع أنه لم يختر شيئاً، لذلك اختر ثلاثاً أو أربعاً هي الأهم لعملك واكتب سبب كل واحدة: متجر إلكتروني في موسم التخفيضات يهمه الأداء والتوافرية، ونظام سجلات طبية يهمه الأمن والسلامة والاعتمادية قبل السرعة، وأداة داخلية لعشرين موظفاً تهمها قابلية الصيانة والكلفة أكثر من أي شيء آخر. وعندما يأتي قرار صعب ترجع إلى هذه القائمة، فهي التي تحسم النقاش بدل الأذواق الشخصية.

من يحتاج ماذا؟

ليس كل فريق يحتاج المستويات الأربعة بنفس الدرجة، والجدول التالي يبين ما يكفي في كل حالة:

وإذا كنت تبني شركة ناشئة وتريد أن ترى كيف تتحول هذه القرارات إلى خطة لكل مرحلة من عمر الشركة، فقد جمعناها في خارطة CTO لشركة SaaS ناشئة.

أخطاء شائعة

• المعماري في البرج العاجي: شخص يرسم المخططات ويسلمها للفريق ثم يغادر، فلا يعرف ما يحدث في الكود، ولا يشعر الفريق بأن القرارات قراراته، والحل أن يعمل المعماري مع الفريق كما يصف Fowler في نموذج Architectus Oryzus.
• تصميم كل شيء مقدماً لمنتج لم يثبت بعد: ثلاثة أشهر من المخططات لنظام لا يعرف أحد هل سيحتاجه السوق، والأفضل أن تتخذ القرارات الصعبة التغيير فقط مبكراً، وتؤجل البقية حتى تعرف أكثر.
• «سنصلح المعمارية لاحقاً»: القرارات المعمارية هي بالتعريف ما يصعب إصلاحه لاحقاً، فإذا أجلت التفكير في ملكية البيانات مثلاً فسوف تجد بعد سنة أن كل جزء يقرأ من جداول الأجزاء الأخرى.
• نسخ معمارية الشركات العملاقة: ما يناسب شركة فيها آلاف المطورين قد يقتل فريقاً من خمسة، وقد رأينا في قصة Stack Overflow كيف خدم موقع ضخم ملايين المستخدمين بتطبيق واحد وسيرفرات قليلة.
• الخلط بين المخطط والمعمارية: يذكر موقع المعيار 42010 أن المعمارية فكرة مجردة وليست ملفاً، وأن المخططات والوثائق اسمها وصف المعمارية Architecture Description، فإذا كان المخطط لا يطابق ما يعمل في الإنتاج فالمعمارية الحقيقية هي ما يعمل، والمخطط هو الذي يحتاج تحديثاً.
• معمارية مؤسسة على الورق فقط: وثائق وإطارات ونماذج لا تغير أي قرار شراء أو تطوير، والسبب غالباً أن فريق المعمارية بعيد عن فرق التطوير، وهي نفس مشكلة البرج العاجي على مستوى أكبر.

مسار القراءة في هذه المرحلة

رتبنا مقالات المرحلة من الأقرب إلى الكود إلى الأبعد عنه، فكل مقال يبني على الذي قبله، والصورة التالية تبين المسار كاملاً:

داخل الكود: ابدأ بمبادئ التصميم SOLID وDRY وKISS وYAGNI والاقتران Coupling والتماسك Cohesion بأمثلة قبل وبعد، ثم أنماط التصميم التي تقابلها فعلاً في .NET وSpring وExpress ومتى تصبح تعقيداً زائداً:

دليلمبادئ التصميم Design Principles بأمثلة قبل وبعدلماذا يكسر تعديل صغير في الفاتورة شيئاً في المحاسبة، وكيف تساعدك مبادئ مثل SOLID وDRY على كود يتغير دون مفاجآت.دليلأنماط التصميم Design Patterns التي تقابلها فعلاًأشهر أنماط التصميم التي تقابلها في كل مشروع، والمشكلة التي يحلها كل نمط، ومتى يصبح عبئاً على من يعدل الكود بعدك.

داخل التطبيق: بعد ذلك اتجاه الاعتماديات في Clean Architecture وHexagonal وOnion مع مشروع صغير يختبر منطق العمل دون قاعدة بيانات، ثم التصميم الموجه بالمجال Domain-Driven Design ببساطة، ثم أنماط المعمارية Architecture Styles مثل Layered وEvent-Driven وModular Monolith وMicrokernel في جدول مقارنة:

دليلClean Architecture: كيف تعزل منطق العمل عن قاعدة البياناتلماذا تحتاج قاعدة بيانات لكي تختبر قاعدة عمل من سطر واحد، وكيف يعزل اتجاه الاعتماديات منطق العمل عن التفاصيل.دليلالتصميم الموجه بالمجال Domain-Driven Design ببساطةلماذا تعني كلمة «الطلب» ثلاثة أشياء في نفس الشركة، وكيف يقسم DDD النظام إلى سياقات لكل منها لغته ونموذجه.دليلأنماط المعمارية Architecture Styles ومتى تختار كلاً منهاكيف تختار بين التطبيق الواحد والخدمات التي تتبادل الأحداث، وما الذي يناسب نظامك من أشهر أنماط المعمارية.

التوثيق: كيف ترسم المعمارية بنموذج C4 كنص داخل المستودع، وكيف تكتب سجل القرارات المعمارية ADR بمثال حقيقي:

دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.

المؤسسة كلها: معمارية المؤسسة وأطرها، وخريطة القدرات ومحفظة التطبيقات، ومعمارية المؤسسة في الجهات الحكومية، وهي المقالات التي عرضناها في قسم معمارية المؤسسة أعلاه.

ومن مرحلة تصميم الأنظمة: إذا لم تقرأ هذه المقالات بعد، فهي تكمل الصورة من جانب التشغيل:

دليلمدخل إلى تصميم الأنظمة: من سيرفر واحد إلى ملايين المستخدمينكيف يكبر متجر إلكتروني من سيرفر واحد إلى نظام يخدم ملايين المستخدمين، وما الثمن الذي تدفعه في كل خطوة.دليلالفرق بين Tiers وLayers: متى يكون نظامك ثلاثي الطبقات فعلاً؟ماذا يعني أن يكون نظامك ثلاثي الطبقات 3-tier فعلاً، والفرق بين الطبقة داخل الكود والمستوى في الشبكة، وما تطلبه الضوابط بالنص.دليلالأنظمة الموزعة للمبتدئين: ماذا يحدث عندما تنقطع الشبكةلماذا تتصرف الأنظمة الموزعة بشكل غريب عند انقطاع الشبكة، وكيف تتفق السيرفرات على قرار واحد رغم ذلك.

وفي مقالات قادمة بإذن الله سوف نكتب عن قرار Monolith أم Microservices للفرق الصغيرة والكبيرة، لأنه أكثر قرار معماري يسأل عنه الناس، وأكثر قرار يتخذ لأسباب خاطئة.

تدريب عملي

1. خذ مشروعاً تعمل عليه الآن واكتب خمسة قرارات اتخذها الفريق فيه، ثم ضع كل قرار على شريط كلفة التغيير في الصورة الثانية: كم سيكلفكم تغييره بعد سنة؟ وهل القرارات التي في الطرف الأحمر مكتوبة أسبابها في مكان يجده مطور جديد؟
2. اختر ثلاث خصائص جودة هي الأهم لهذا المشروع، واكتب كل واحدة كجملة فيها رقم يمكن قياسه، ثم اسأل نفسك: هل يقيس النظام اليوم هذا الرقم فعلاً؟

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• تصميم البرمجيات ومعمارية البرمجيات وتصميم الأنظمة ومعمارية المؤسسة نفس النشاط من أربع مسافات: الكود داخل الميزة، ثم أجزاء التطبيق، ثم التشغيل تحت الحمل، ثم كل أنظمة المؤسسة.
• المعمارية هي القرارات المهمة، والمهم هو ما يصعب ويكلف تغييره، والتصميم ينظر إلى داخل الحدود بينما تنظر المعمارية إلى النظام داخل بيئته.
• تصميم الأنظمة يتداخل مع المعمارية ويركز على السيرفرات والبيانات والتوسع والأعطال، وله مرحلة كاملة في خارطة الطريق.
• معمارية المؤسسة تحتاجها المؤسسات الكبيرة والجهات الحكومية لتعرف ما تملكه وتقرر ما تبقيه وما تستبدله، ولا تحتاجها شركة بنظام واحد.
• كلما طال عمر القرار اتسعت دائرة من يشارك فيه، ووجب أن يكتب سببه، وشكل الفرق يحدد شكل النظام كما يقول قانون Conway.
• خصائص الجودة هي ما تحميه المعمارية فعلاً، فاكتبها بالأرقام، واختر القليل الذي يهم عملك، وتذكر أن كل خاصية تحسنها لها ثمن في خاصية أخرى.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، ومراجعة التعريفات من صفحة المعيار ISO/IEC/IEEE 42010 وSEI ومقال Who Needs an Architect? ودليل Martin Fowler، وخصائص الجودة من نموذج ISO/IEC 25010:2023 وإطاري Azure وAWS Well-Architected.