أساسيات التصميم المعماري

أساسيات التصميم المعماري

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

يُقدّم هذا الدرس المفردات وأدوات التفكير التي تحتاجها للمشاركة في قرارات المعمارية العالية المستوى ومراجعتها وتوثيقها — الطبقات، والمستويات، والنمط الثلاثي الكلاسيكي الذي يُشكّل الركيزة الأساسية لغالبية أنظمة معلومات الأعمال المبنية اليوم.

الطبقات مقابل المستويات — تمييز جوهري

مصطلحان كثيراً ما يُخلط بينهما هما الطبقة (Layer) والمستوى (Tier). فهم الفرق يمنع سوء الفهم المكلف خلال مراجعات التصميم.

• الطبقة مفهوم منطقي — تجميع الكود حسب المسؤولية. الطبقات تتواجد كتقاليد تصميمية فقط؛ يمكن أن تعمل جميعها على جهاز واحد. النموذج الكلاسيكي ذو الثلاث طبقات يُجمّع الكود في: Presentation (منطق واجهة المستخدم)، وBusiness Logic (القواعد والسير التجاري)، وData Access (القراءة والكتابة على التخزين).
• المستوى مفهوم مادي — بيئة تشغيل مستقلة قابلة للنشر، تعمل عادةً على جهاز أو حاوية مخصصة. تتواصل المستويات عبر شبكة. النظام ذو المستويين يضم عميلاً وخادم قاعدة بيانات. النظام ذو الثلاثة مستويات يُضيف خادم تطبيق مخصصاً بينهما.

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

معمارية الثلاثة مستويات بالتفصيل

تأمّل نظام حجز مواعيد عيادة. على أوسع مستوى، يحتاج إلى: عرض النماذج والتقويمات للمرضى والموظفين (مستوى العرض)، وتطبيق قواعد مثل "لا حجز مزدوج" و"الموعد يجب أن يكون 30 دقيقة على الأقل" (مستوى التطبيق)، وتخزين المرضى والأطباء والفترات الزمنية والمواعيد واسترجاعها (مستوى البيانات). هذه المسؤوليات الثلاث تُعيَّن بوضوح على ثلاثة مستويات:

لاحظ عدة خصائص مهمة في هذا المخطط:

• قاعدة الجار المباشر: مستوى العرض لا يتواصل مطلقاً مباشرةً مع مستوى البيانات. كل وصول للبيانات يجب أن يمر عبر مستوى التطبيق الذي يُطبّق قواعد الأعمال. في نظام العيادة، هذا يمنع المتصفح من الاستعلام عن قاعدة البيانات مباشرةً وتجاوز قاعدة "لا حجز مزدوج".
• قابلية التوسع المستقلة: إذا ارتفعت الحجوزات في الساعة 8 صباحاً كل يوم، يمكن للمنظمة إضافة المزيد من خوادم مستوى التطبيق دون المساس بقاعدة البيانات أو الواجهة الأمامية. كل مستوى يتوسع باستقلالية.
• استبدال التقنية: يمكن لمستوى البيانات الانتقال من MySQL إلى PostgreSQL دون تغيير مستوى العرض. طبقة الوصول للبيانات في مستوى التطبيق تمتص هذا التغيير. لهذا السبب تُسمى طبقة الوصول للبيانات أحياناً حد التجريد.

أنماط المعمارية الشائعة

المعمارية ثلاثية المستويات هي النمط السائد لأنظمة الأعمال، لكنها ليست الوحيدة. بوصفك محللاً، ستصادف عدة أنماط؛ التعرف عليها يتيح لك طرح الأسئلة الصحيحة وتوثيق القيود المناسبة.

• المونوليث (Monolithic): جميع الطبقات مُعبَّأة كوحدة نشر واحدة. شائع في الأنظمة الصغيرة والمنتجات في مراحلها الأولى. بسيط في التطوير والنشر في البداية؛ يصبح صعب التوسع أو التغيير المستقل مع نمو النظام. متجر إلكتروني به جميع الوظائف في تطبيق PHP واحد هو مونوليث.
• الخدمات المصغرة (Microservices): كل قدرة تجارية (الطلبات، المخزون، المدفوعات، الإشعارات) تصبح خدمة مستقلة بقاعدة بيانات خاصة بها، قابلة للنشر منفصلةً. تُمكّن الفرق من الإصدار المستقل وتوسيع نقاط الاختناق المحددة — لكنها تُدخل كمون الشبكة وتعقيد المعاملات الموزعة وعبئاً تشغيلياً أعلى. شركات اللوجستيات ذات الحجم العالي وتتبع الوقت الفعلي كثيراً ما تتطور نحو الخدمات المصغرة.
• المعمارية المبنية على الأحداث (Event-Driven): تتواصل الخدمات بنشر الأحداث واستهلاكها عبر وسيط رسائل (مثل Kafka أو RabbitMQ). تنشر خدمة الطلبات حدث OrderPlaced؛ تستجيب خدمة المخزون وخدمة الإشعارات كل منها باستقلالية. تُفصل المنتجين عن المستهلكين لكن تُعقّد تصحيح الأخطاء وضمانات الاتساق.
• السيرفرليس (Serverless): يعمل منطق الأعمال في دوال عديمة الحالة (AWS Lambda، Azure Functions) تُستدعى عند الطلب. لا خوادم للإدارة، وتوسع تلقائي، ودفع بالاستدعاء — لكن كمون البدء البارد وارتباط البائع مخاوف حقيقية للمعاملات الحساسة للكمون.

كيف يستخدم المحلل معرفته بالمعمارية

أنت لا تختار المعمارية — لكنك تؤثر فيها. إليك كيف يرتبط عملك التحليلي بكل مستوى:

• تصميم مستوى العرض يتشكّل من حالات الاستخدام والنماذج الأولية وقصص المستخدم. إذا نصّت حالة الاستخدام على أن مشرف الشحن يجب أن يُحدّث 50 حالة شحن في وقت واحد، فإن مستوى العرض يحتاج شبكة تحرير جماعي، لا 50 نموذجاً منفصلاً — وهذا يُحدد ما إذا كانت صفحة ذات خادم خفيف كافية أم أن تطبيق صفحة واحدة (SPA) ضروري.
• تصميم مستوى التطبيق يتشكّل من قواعد الأعمال وسير العمل ومتطلبات التكامل. كل قاعدة أعمال وثّقتها في SRS ("لا يستطيع المريض حجز موعد قبل ساعتين من الوقت الحالي") تصبح طريقة خدمة أو تحقق أو كائن سياسة. القواعد المعقدة تعني مستوى تطبيق أغنى.
• تصميم مستوى البيانات يتدفق مباشرةً من ERD الخاص بك. كل كيان في ERD يُعيَّن على جدول في قاعدة البيانات (أو مجموعة في مخزن NoSQL). العلاقات التي حددتها (مريض لديه مواعيد متعددة؛ موعد ينتمي لطبيب واحد فقط) تُملي المفاتيح الأجنبية وجداول الربط والفهارس. مستوى البيانات هو ERD مُنفَّذ عملياً.

توثيق المعمارية

قرارات المعمارية تحتاج توثيقاً — عادةً في وثيقة مواصفات التصميم (تُغطَّى في الدرس السابع). وصف معماري مختصر يشمل:

1. النمط المعماري: "ثلاثية المستويات، عميل-خادم." اذكر هذا صراحةً. لا تفترض أن الجميع يتشاركون نفس النموذج الذهني.
2. مسؤوليات كل مستوى: فقرة واحدة لكل مستوى تصف ما يتعامل معه وما لا يتعامل معه.
3. بروتوكولات الاتصال: "العرض إلى التطبيق عبر HTTPS REST API (JSON). التطبيق إلى البيانات عبر SQLAlchemy ORM على اتصال TCP بـ PostgreSQL على المنفذ 5432."
4. مكدس التقنيات لكل مستوى: "React 18 (العرض)، Node.js / Express (التطبيق)، PostgreSQL 16 (البيانات)."
5. القرارات المعمارية الرئيسية ومبرراتها: "اخترنا نشراً أحادياً للإصدار الأولي لأن الفريق يضم أربعة مطورين، وقاعدة المستخدمين أقل من 1,000، وتقسيم الخدمات المصغرة سيضيف تعقيداً تشغيلياً لا يستطيع الفريق دعمه بعد."

هذا المستوى من التوثيق كافٍ للمحلل لتتبع المتطلبات إلى مكونات التصميم في مصفوفة التتبع، مما يُمكّن فريق الاختبار من التخطيط لبنية الاختبار المناسبة. كل متطلب وظيفي يجب أن يُعيَّن على مكوّن واحد على الأقل في مستوى التطبيق، وكل متطلب بيانات يجب أن يُعيَّن على كيان واحد على الأقل في مستوى البيانات. ستُطبّق هذا التعيين عملياً في الدرس التاسع (التتبع من المتطلبات إلى التصميم).