الأنماط المعمارية وتوثيق المعمارية
ما الأنماط المعمارية الشائعة لتطبيقات الويب، وكيف توثّق معمارية مشروعك بمخطط واضح؟ ⏱ نحو 45 دقيقة.
- تقارن المتجانس والخدمات المصغرة وبلا خادم، وتختار المناسب لحجم المشروع.
- تقارن صفحات الخادم بالواجهة المنفصلة مع
API. - ترسم مخطط حاويات بالبروتوكولات والأنظمة الخارجية.
- تربط القرارات المعمارية بالمتطلبات غير الوظيفية وتوثقها.
١المتجانس أم الخدمات المصغرة؟
النمط المعماري طريقة مجرّبة لتنظيم النظام كله، كما أن MVC نمط لتنظيم الكود داخل الخادم. أهم قرار هنا: هل نبني النظام تطبيقًا واحدًا أم خدمات منفصلة؟
| النمط | الفكرة | يناسب | ثمنه |
|---|---|---|---|
| المتجانس Monolith | تطبيق واحد يُنشر مرة واحدة، مقسّم داخليًّا (MVC) | أغلب المشاريع الصغيرة والمتوسطة وبداية أي مشروع | إن كبر جدًّا يصعب على فرق كثيرة العمل فيه معًا |
| الخدمات المصغرة Microservices | خدمات مستقلة (التسجيل، والدفع، والرسائل) لكل منها بياناتها ونشرها | أنظمة ضخمة بفرق متعددة واحتياجات توسع مختلفة | تعقيد كبير: شبكة، ومراقبة، وبيانات موزعة |
| بلا خادم Serverless | دوال صغيرة تعمل عند الطلب على منصة سحابية | أعمال متقطعة، ومهام خلفية | الاعتماد على مزود واحد، وصعوبة التتبع |
٢صفحات من الخادم، أم واجهة منفصلة مع API؟
| صفحات يولدها الخادم | واجهة SPA + API | |
|---|---|---|
| كيف يعمل | الخادم يرسل HTML كاملًا لكل صفحة | الخادم يرسل JSON، والواجهة ترسم الصفحة |
| المزايا | بسيط، وسريع في البناء، وجيد لمحركات البحث | تفاعل كثيف، وAPI واحدة تخدم الموقع وتطبيق الجوال |
| العيوب | تفاعل أقل | مشروعان بدل مشروع، ومصادقة بالرموز |
| في «دورات» | لوحة الإدارة (Blade) | واجهة المتدرب (React) لأن تطبيق الجوال قادم |
لاحظ أن النظام الواحد قد يجمع الأسلوبين؛ المهم أن يُوثّق القرار وسببه.
٣مخطط الحاويات: المعمارية في صورة واحدة
نموذج C4 شائع لتوثيق المعمارية بمستويات تكبير: السياق (النظام والمستخدمون والأنظمة الخارجية)، ثم الحاويات (التطبيقات وقواعد البيانات القابلة للنشر)، ثم المكونات، ثم الكود. أهمها للمواصفات التقنية مخطط الحاويات:
flowchart LR U[المتدرب والموظفون] subgraph B[المتصفح] spa[واجهة React] end subgraph S[خادم التطبيق] api[API بـ Laravel] q[مهام الخلفية: الرسائل والتقارير] end subgraph D[البيانات] db[(MySQL)] fs[(ملفات الشهادات)] end pay[بوابة الدفع] sms[خدمة الرسائل النصية] U -- HTTPS --> spa spa -- JSON عبر HTTPS --> api api -- SQL --> db api -- مهمة --> q q -- SQL --> db q -- API --> sms api -- API --> pay api -- قراءة وكتابة --> fs
كل مجموعة حاوية تعمل في مكان مختلف، وكل سهم يذكر البروتوكول (HTTPS، SQL، API). لاحظ: لا سهم من المتصفح إلى قاعدة البيانات. ومهام الخلفية تفصل الأعمال البطيئة (الرسائل، والتقارير) حتى لا ينتظرها المستخدم.
٤القرارات المعمارية تخدم المتطلبات غير الوظيفية
المعمارية ليست ذوقًا؛ كل قرار فيها يجيب عن متطلب غير وظيفي. وثّق هذا الربط في مستند المواصفات، فيفهم أي مطور لماذا البنية هكذا:
| المتطلب غير الوظيفي | القرار المعماري |
|---|---|
NFR-01: 300 مستخدم متزامن يوم التسجيل | خادم تطبيق بلا حالة stateless يمكن نسخه خلف موزع أحمال عند الحاجة |
| NFR-03: حماية الحسابات | المصادقة والصلاحيات في طبقة API فقط، والواجهة لا تملك أي سر |
| NFR-05: الرسالة خلال دقيقة من الاعتماد | قائمة مهام خلفية للرسائل مع إعادة المحاولة |
| NFR-06: البيانات داخل المملكة | استضافة الخادم وقاعدة البيانات لدى مزود محلي |
| المرحلة الثانية: تطبيق جوال | API مستقلة بصيغة JSON تخدم الموقع والتطبيق |
توقّع وتحقّق
نظام لمركز تدريب بفريق من مطورَين. أنسب نمط:
لماذا اخترنا API منفصلة لواجهة المتدرب؟
في مخطط الحاويات، ماذا يُكتب على الأسهم؟
إرسال الرسائل النصية في مهام خلفية يخدم:
الخلاصة
- ابدأ متجانسًا منظّمًا؛ الخدمات المصغرة للأنظمة الضخمة بفرق كثيرة.
- صفحات الخادم أبسط، و
SPA + APIلتفاعل كثيف أو تطبيق جوال. C4: سياق، ثم حاويات، ثم مكونات؛ ومخطط الحاويات بالبروتوكولات أهمها للمواصفات.- كل قرار معماري يُبرَّر بمتطلب غير وظيفي ويُوثَّق.
تحدٍّ تصميمي: مخطط حاويات «دورات»
متوسطأكمل مخطط الحاويات لنظام «دورات» بحيث يصلح لمستند المواصفات التقنية.
- ثلاث حاويات بـ
subgraph: المتصفح، والخادم، والبيانات. - قاعدة البيانات أسطوانة داخل حاوية البيانات، والخادم يتصل بها.
- نظامان خارجيان خارج الحاويات: بوابة الدفع وخدمة الرسائل، يتصل بهما الخادم.
- كل سهم يحمل البروتوكول أو نوع الاتصال.
- لا اتصال مباشر بين الواجهة وقاعدة البيانات.
- المخطط مكتوب بصيغة صحيحة ويُرسم
- نوعه: مخطط تدفق flowchart
- ثلاث حاويات subgraph
- قاعدة بيانات (أسطوانة)
- الخادم يتصل بقاعدة البيانات
- الخادم يتصل ببوابة الدفع
- الخادم يتصل بخدمة الرسائل
- كل سهم يحمل البروتوكول
- لا اتصال بين الواجهة وقاعدة البيانات
💡 تلميح 1
db[(قاعدة البيانات)] داخل subgraph D[البيانات] … end.💡 تلميح 2
pay[بوابة الدفع].💡 تلميح 3
api -- SQL --> db.حاول بنفسك أولًا؛ للتصميم أكثر من حلّ صحيح، والفحص يتأكد من العناصر الأساسية فقط.
flowchart LR subgraph B[المتصفح] spa[الواجهة] end subgraph S[الخادم] api[API] end subgraph D[البيانات] db[(قاعدة البيانات)] end pay[بوابة الدفع] sms[خدمة الرسائل] spa -- JSON عبر HTTPS --> api api -- SQL --> db api -- API --> pay api -- API --> sms