> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# المخططات التقنية Diagrams: ماذا ترسم ومتى؟
- URL: https://arabroot.io/articles/المخططات-التقنية-diagrams-ماذا-ترسم-ومتى/
- Published: 2026-10-23T06:00:00.000Z
- Updated: 2026-10-23T15:09:34.000Z
- Description: كيف تختار نوع المخطط من سؤال القارئ، ومتى ترسم باليد أو بالكود، وكيف تبقيه صحيحاً ومقروءاً بالعربية.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, تطبيقات لفريقك, الاستضافة الذاتية, Diagrams

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

المواضيع في السلسلة:

- المخططات التقنية Diagrams: ماذا ترسم ومتى؟ (الموضوع الحالي)
- [أدوات رسم المخططات Diagrams: مقارنة عملية](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-diagrams-%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-%D8%B9%D9%85%D9%84%D9%8A%D8%A9/)
- [Excalidraw على سيرفرك مع الرسم المشترك](https://arabroot.io/articles/excalidraw-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D9%85%D8%B9-%D8%A7%D9%84%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%B4%D8%AA%D8%B1%D9%83/)

وفي هذا المقال سوف نتناول:

- ما الذي يجعل المخطط مفيداً، ولماذا يبدأ من سؤال القارئ.
- أشهر ستة أنواع من المخططات التقنية: المعمارية Architecture والتسلسل Sequence والتدفق Flowchart والكيانات والعلاقات ERD والشبكة Network ورسم السبورة Whiteboard Sketch.
- من يقرأ المخطط، وكيف يتغير مستوى التفاصيل Detail بحسب القارئ.
- الرسم باليد في أداة رسم، أم كتابة المخطط ككود Diagram as Code، ومتى يناسب كل منهما.
- كيف تبقي المخطط صحيحاً بعد أن يتغير النظام.
- النص العربي داخل المخطط: ترتيب الكلمات والخطوط واتجاه التدفق.

## لماذا نرسم أصلاً؟

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

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

## ستة أنواع من المخططات Diagrams تغطي أغلب ما تحتاجه

هناك عشرات الأنواع من المخططات في UML وغيرها، ولكن أغلب ما يحتاجه فريق تقني في عمله اليومي يقع في ستة أنواع، والصورة التالية تبين كل نوع والسؤال الذي يجيب عنه:

![ست بطاقات: مخطط المعمارية Architecture فيه Web App وAPI وقاعدة بيانات داخل حد منقط ونظام Payments خارجه، ومخطط التسلسل Sequence فيه ثلاثة خطوط Browser وAPI وIdP ورسائل بينها، ومخطط التدفق Flowchart فيه طلب ثم قرار مقبول ثم تنفيذ أو رفض، ومخطط الكيانات والعلاقات ERD فيه جدولان customer وorder بعلاقة 1 إلى N، ومخطط الشبكة Network فيه الإنترنت والجدار الناري والـ Load Balancer وسيرفران وقاعدة بيانات، ورسم السبورة فيه مربع وشكل بيضاوي مرسومان باليد وسؤال هل نحتاج Cache هنا](https://arabroot.io/content/images/2026/10/diagrams-concept-01-types.webp)

لكل نوع سؤال يجيب عنه، والأدوات المكتوبة تحت كل نوع أمثلة وليست قائمة كاملة

وفيما يلي كل نوع باختصار، ومتى تحتاجه:

- **مخطط المعمارية Architecture Diagram**: يبين مم يتكون النظام ومع من يتكلم، والطريقة الأوضح لرسمه هي [نموذج C4](https://c4model.com/?ref=arabroot.io) بمستوياته الأربعة، وقد شرحناه بالتفصيل مع أمثلة ومخططات ككود في [مقال توثيق المعمارية بمخططات C4 وسجلات ADR](https://arabroot.io/articles/%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-c4-%D9%88-adr/)، فلن نعيده هنا.
- **مخطط التسلسل Sequence Diagram**: يبين من يرسل ماذا ولمن وبأي ترتيب في عملية واحدة، مثل تسجيل الدخول أو الدفع، وهو أفضل ما يشرح مشكلة تحدث في الخطوة الرابعة من سبع خطوات، لأن الترتيب الزمني هو المحور الأساسي فيه.
- **مخطط التدفق Flowchart**: يبين خطوات إجراء وأين يتفرع القرار، مثل إجراء الموافقة على طلب شراء أو خطوات الاستجابة لحادث، وإذا كان الإجراء يشمل أكثر من قسم ويحتاج دقة رسمية فهناك ترميز BPMN المخصص لإجراءات الأعمال.
- **مخطط الكيانات والعلاقات Entity Relationship Diagram** واختصاراً ERD: يبين الجداول وأعمدتها المهمة والعلاقات بينها، ويحتاجه كل من يكتب استعلاماً أو يغير بنية قاعدة البيانات، وقد تحدثنا عن التصميم نفسه في [مقال تصميم قواعد البيانات](https://arabroot.io/articles/%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D8%B9-%D9%88%D8%A7%D9%84%D8%AA%D9%88%D8%B3%D8%B9/).
- **مخطط الشبكة Network Diagram**: يبين أين يعمل كل شيء، والشبكات الفرعية Subnets والعناوين والمنافذ Ports والجدران النارية Firewalls بينها، وهو الذي يبحث عنه المهندس المناوب في القصة أعلاه، ويرتبط مباشرة بـ [تقسيم الشبكة Network Segmentation](https://arabroot.io/articles/%D8%AA%D9%82%D8%B3%D9%8A%D9%85-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-network-segmentation-vlan-%D9%88-vpc/).
- **رسم السبورة Whiteboard Sketch**: رسم سريع غير رسمي أثناء النقاش، والهدف منه التفكير وليس التوثيق، لذلك فشكله الذي يشبه خط اليد مقصود، فهو يقول للحاضرين إن هذه فكرة قابلة للنقاش وليست قراراً نهائياً.

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

### مثال: مخطط تسلسل Sequence مكتوب كنص

لكي نرى الفرق بين النوع والأداة، لنأخذ عملية تسجيل الدخول، ونكتبها بصيغة [Mermaid لمخططات التسلسل](https://mermaid.js.org/syntax/sequenceDiagram.html?ref=arabroot.io)، وهي نص عادي يحفظ في ملف داخل المستودع:

```text
sequenceDiagram
    autonumber
    participant B as المتصفح Browser
    participant A as الخادم API
    participant I as مزود الهوية IdP
    B->>A: POST /login
    A->>I: التحقق من الحساب
    I-->>A: Token
    A-->>B: 200 OK + Cookie
```

وعند تحويل الملف إلى صورة بأداة `mmdc` من mermaid-cli داخل Docker سوف تحصل على المخطط التالي:

```bash
docker run --rm -v "$PWD":/data minlag/mermaid-cli:12.0.1 \
  -i login-sequence.mmd -o login-sequence.png -s 2 -b white
```

![مخطط تسلسل فيه ثلاثة مشاركين: المتصفح Browser والخادم API ومزود الهوية IdP، وأربع رسائل مرقمة: POST /login من المتصفح إلى الخادم، ثم التحقق من الحساب من الخادم إلى مزود الهوية، ثم Token راجعة إلى الخادم، ثم 200 OK + Cookie راجعة إلى المتصفح](https://arabroot.io/content/images/2026/10/diagrams-concept-05-mermaid-sequence.webp)

نفس العملية من ملف نصي من تسعة أسطر، والأرقام يضيفها `autonumber` تلقائياً

في المثال أعلاه لاحظ التالي:

- السهم المتصل `->>` طلب، والسهم المنقط `-->>` رد، وهذا الفرق وحده يجعل المخطط مقروءاً دون شرح.
- أسماء المشاركين عربية ومعها المصطلح الإنجليزي، وظهرت الحروف العربية سليمة، وسوف نرى في [قسم العربية](#arabic) أن هذا ليس مضموناً في كل أداة.
- إذا أضاف أحدهم خطوة جديدة مثل التحقق الثنائي فسوف تظهر في المراجعة سطراً واحداً جديداً، وليس صورة جديدة لا يعرف أحد ما الذي تغير فيها.

## لمن ترسم؟ القارئ Audience قبل الأداة

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

![أربعة أعمدة: الإدارة Management تسأل ما الذي نملكه وبماذا نعتمد على جهات خارجية ويناسبها مخطط السياق بتفاصيل قليلة، والمطور الجديد New Developer يسأل أين أبدأ ويناسبه مخطط التطبيقات ومخطط تسلسل بتفاصيل متوسطة، وفريق التشغيل Operations يسأل على أي سيرفر يعمل هذا وما المنافذ ويناسبه مخطط الشبكة والنشر بتفاصيل كثيرة، والمدقق Auditor يسأل أين تمر البيانات الشخصية ويناسبه مخطط تدفق البيانات مع حدود الثقة](https://arabroot.io/content/images/2026/10/diagrams-concept-02-audience.webp)

كلما اقترب القارئ من التشغيل اليومي زادت التفاصيل التي يحتاجها

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

1. **عنوان يقول ماذا يبين المخطط**: «مخطط الشبكة لبيئة الإنتاج Production» وليس «Diagram 1»، والسبب أن الصورة سوف تنسخ إلى عرض تقديمي أو رسالة بريد بعيداً عن الصفحة التي تشرحها.
2. **مفتاح Legend للألوان والأشكال**: إذا كان اللون الرمادي يعني نظاماً خارجياً فاكتب ذلك، وإلا ظن القارئ أنه نظام متوقف.
3. **وصف على كل سهم**: «يرسل الفواتير عبر HTTPS» وليس سهماً فارغاً، لأن السهم الفارغ قد يعني طلباً أو اعتماداً أو نقل بيانات، وكل قارئ سوف يختار معنى مختلفاً.
4. **مستوى واحد في المخطط الواحد**: لا تخلط الخدمات مع جداول قاعدة البيانات مع عناوين IP في صورة واحدة، وارسم مخططاً لكل مستوى.
5. **تاريخ واسم مسؤول**: سطر صغير في زاوية المخطط «آخر تحديث: أكتوبر 2026، فريق المنصة»، وهو أرخص وسيلة ليعرف القارئ هل يثق بما يراه.

## ترسم على لوحة Canvas أم تكتب المخطط ككود Diagram as Code؟

هناك عائلتان من الأدوات: أدوات الرسم على لوحة Canvas مثل draw.io وExcalidraw وVisio، حيث تسحب الأشكال بالفأرة وتضعها حيث تريد، وأدوات المخططات ككود Diagram as Code مثل Mermaid وPlantUML وD2، حيث تكتب نصاً يصف العناصر والعلاقات، والأداة ترتب الرسم بنفسها. ولكل عائلة مكانها، والجدول التالي يلخص الفرق:

| المعيار                      | الرسم على لوحة Canvas                                    | المخطط ككود Diagram as Code                               |
| ---------------------------- | -------------------------------------------------------- | --------------------------------------------------------- |
| السرعة في أول مرة            | سريع، ترسم ما في رأسك مباشرة                             | يحتاج تعلم الصيغة Syntax، ثم يصبح أسرع من الرسم           |
| التحكم في الشكل              | كامل، كل شكل في المكان الذي تختاره                       | محدود، محرك الترتيب Layout Engine يقرر أغلب المواقع       |
| المراجعة في الـ Pull Request | ترى أن الملف تغير، ولا ترى ماذا تغير                     | كل تغيير سطر واضح في الـ diff                             |
| التحديث بعد سنة              | يحتاج أن يفتح أحدهم الملف ويحرك الأشكال يدوياً           | تعديل سطر، والصورة تتولد من جديد                          |
| من يستطيع التعديل            | أي شخص، حتى غير التقني                                   | من يعرف الصيغة ويصل إلى المستودع                          |
| أنسب استخدام                 | مخطط الشبكة المفصل، ورسم النقاش، والعرض على غير التقنيين | التسلسل والتدفق وERD، وكل مخطط يعيش بجانب الكود الذي يصفه |

ولاحظ أن الاختيار ليس واحداً للمؤسسة كلها، وإنما لكل مخطط، فقد ترسم نقاش التصميم على Excalidraw، ثم تكتب النتيجة النهائية كمخطط تسلسل بصيغة Mermaid داخل ملف README، لأن [GitHub يعرض Mermaid داخل ملفات Markdown](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams?ref=arabroot.io) مباشرة دون أن تحول الملف إلى صورة. أما فكرة النموذج الواحد الذي تتولد منه كل مخططات المعمارية فقد شرحناها مع Structurizr في [قسم المخططات ككود](https://arabroot.io/articles/%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-c4-%D9%88-adr/#diagrams-as-code) من مقال توثيق المعمارية.

## كيف يبقى المخطط صحيحاً؟

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

![ثلاثة أعمدة: صورة فقط باللون الأحمر، لقطة شاشة architecture.png في صفحة Wiki والمصدر على جهاز من رسمها، ثم صورة ومعها المصدر باللون الأصفر مثل network.drawio.svg وflow.excalidraw.png والمصدر داخل الصورة يفتحه أي شخص ويعدله، ثم نص يولد الصورة باللون الأخضر مثل docs/login-flow.mmd يعيش في المستودع وكل تغيير يظهر في الـ diff](https://arabroot.io/content/images/2026/10/diagrams-concept-03-keep-source.webp)

الطريقة الأولى هي ما تجده في أغلب الشركات، والثانية والثالثة هما ما يجب أن يكون

والطريقة الوسطى أقل شهرة مما تستحق، فأداة draw.io تحفظ المخطط داخل ملف PNG أو SVG نفسه، وتسمي [صفحة صيغ الملفات](https://www.drawio.com/doc/faq/save-file-formats?ref=arabroot.io) هذه الملفات «Editable Bitmap» و«Editable Vector»، أي أنك تضع الصورة في الـ Wiki أو في الـ README كأي صورة عادية، ومن يريد تعديلها يفتحها في draw.io فيجد المخطط كاملاً بأشكاله ونصوصه. ونفس الفكرة موجودة في Excalidraw، حيث يوجد في نافذة التصدير خيار Embed scene يضع بيانات الرسم داخل الصورة المصدرة.

وفيما يلي ما ننصح به لكي لا تتقادم المخططات:

- **المصدر بجانب الكود**: ضع ملفات المخططات في مجلد `docs/diagrams` داخل المستودع نفسه، والسبب أن الشخص الذي يغير الكود هو الأقرب لمعرفة أن المخطط تغير.
- **سؤال في قالب الـ Pull Request**: أضف سطراً «هل يغير هذا التعديل أي مخطط في docs/diagrams؟»، فالسؤال يذكر المراجع والكاتب في اللحظة المناسبة.
- **مسؤول لكل مخطط**: فريق وليس شخصاً، لأن الشخص يغادر والفريق يبقى.
- **احذف القديم**: المخطط الذي لم يعد صحيحاً ولن يحدثه أحد احذفه أو اكتب عليه بخط واضح «قديم»، ولا تتركه يضلل من يجده بالبحث.
- **لا تحفظ في مكان لا يصل إليه الفريق**: إذا كان المخطط في حساب شخصي على خدمة سحابية فهو ملك ذلك الشخص فعلياً، وإذا كانت بيانات الشبكة حساسة فالأفضل أداة تعمل على سيرفرك، وهو موضوع [المقال الثالث من السلسلة](https://arabroot.io/articles/excalidraw-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D9%85%D8%B9-%D8%A7%D9%84%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%B4%D8%AA%D8%B1%D9%83/).

## العربية واتجاه النص RTL داخل المخطط

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

![ثلاث بطاقات: الأولى ترتيب الكلمات Bidi، نفس التسمية الخادم API Server مرة باتجاه LTR فتأتي الكلمة الإنجليزية على اليمين، ومرة باتجاه RTL فتأتي العربية أولاً؛ والثانية خط بلا حروف عربية تظهر فيه الحروف مربعات Tofu بجانب API Server ثم خط عربي يظهر فيه النص سليماً؛ والثالثة اتجاه التدفق، أسهم من اليسار إلى اليمين بين الطلب والخادم والرد، ثم نفس الأسهم من اليمين إلى اليسار](https://arabroot.io/content/images/2026/10/diagrams-concept-04-rtl.webp)

ثلاث مشكلات مستقلة، والأداة قد تنجح في واحدة وتفشل في أخرى

1. **ترتيب الكلمات Bidi**: النص الذي يجمع العربية والإنجليزية يرتب بحسب [خوارزمية الاتجاه الثنائي في Unicode](https://www.unicode.org/reports/tr9/?ref=arabroot.io)، ونتيجتها تعتمد على اتجاه الفقرة الأساسي Base Direction، فإذا كانت الأداة تعتبر كل تسمية LTR فسوف يقرأ العربي «API Server» قبل «الخادم». والحل في الأدوات التي تقبل HTML هو تحديد الاتجاه كما تشرح [إرشادات W3C للنص ثنائي الاتجاه](https://www.w3.org/International/articles/inline-bidi-markup/?ref=arabroot.io)، وفي الأدوات الأخرى خيار في التنسيق أو وضع المصطلح الإنجليزي في سطر ثان.
2. **الخط Font**: الأدوات التي ترسم الصورة على السيرفر، مثل أدوات المخططات ككود عند تحويلها إلى PNG، تستخدم الخطوط الموجودة معها، فإذا لم يكن فيها خط عربي ظهرت الحروف مربعات فارغة، وهذا ما حدث فعلاً في اختبارنا لأداة D2 قبل أن نعطيها خطاً عربياً.
3. **اتجاه التدفق Flow Direction**: القارئ العربي يبدأ من اليمين، فإذا رسمت مخطط تدفق يبدأ من اليسار في مقال عربي فسوف تبدأ عينه من النهاية، والحل البسيط الذي يعمل في كل الأدوات هو التدفق من الأعلى إلى الأسفل.

وقد اختبرنا هذه النقاط الثلاث فعلياً في ست أدوات بنفس المخطط، والنتائج مع الصور في [قسم اختبار العربية](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-diagrams-%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-%D8%B9%D9%85%D9%84%D9%8A%D8%A9/#arabic) من المقال التالي.

💡

أسماء الخدمات والمكونات التي تظهر في الكود، مثل `billing-api` أو `orders`، اكتبها في المخطط كما هي في الكود بالإنجليزية، واكتب الشرح بالعربية تحتها، والسبب أن المهندس سوف يبحث عن الاسم نفسه في السجلات Logs وفي لوحة المراقبة.

## أخطاء شائعة

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

## تدريب عملي

1. اختر نظاماً تعمل عليه، واكتب ثلاثة أسئلة يسألها شخص جديد في أسبوعه الأول، ثم حدد لكل سؤال نوع المخطط الذي يجيب عنه من الأنواع الستة.
2. اكتب مخطط التسلسل لأهم عملية في النظام بصيغة Mermaid، وضعه في ملف README، وتأكد من أن GitHub أو GitLab يعرضه، ثم اطلب من زميل لم يعمل على هذه العملية أن يشرحها لك من المخطط فقط.
3. ابحث في الـ Wiki عن أقدم مخطط شبكة أو معمارية، وقارنه بالنظام الحالي، ثم قرر: تحديث، أو كلمة «قديم» في العنوان، أو حذف.

## الخلاصة

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

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

وفي المقال القادم بإذن الله سوف نقارن أدوات الرسم مفتوحة المصدر والتجارية، ونختبر دعمها للعربية بنفس المخطط:

[![](https://arabroot.io/content/images/2026/10/diagram-tools-cover-cover.webp)دليلأدوات رسم المخططات Diagrams: مقارنة عمليةمقارنة أدوات الرسم مفتوحة المصدر والتجارية بالترخيص والاستضافة والرسم المشترك وGit، مع اختبار فعلي للعربية.](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-diagrams-%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-%D8%B9%D9%85%D9%84%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/excalidraw-lab-cover-cover.webp)دليلExcalidraw على سيرفرك مع الرسم المشترككيف تبني Excalidraw وخادم الغرف على سيرفرك لترسم مع فريقك في نفس اللوحة دون أن يمر رسمك بخدمة خارجية.](https://arabroot.io/articles/excalidraw-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83-%D9%85%D8%B9-%D8%A7%D9%84%D8%B1%D8%B3%D9%85-%D8%A7%D9%84%D9%85%D8%B4%D8%AA%D8%B1%D9%83/)[![](https://arabroot.io/content/images/2026/10/architecture-docs-cover-cover.webp)دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.](https://arabroot.io/articles/%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AE%D8%B7%D8%B7%D8%A7%D8%AA-c4-%D9%88-adr/)

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

- أكتوبر 2026: كتابة المقال، وتوليد مثال مخطط التسلسل بأداة mermaid-cli 12.0.0 (minlag/mermaid-cli:12.0.1) على Docker Engine 29.8.0.