الهندسة المعمارية

# /architecture

> إذا رأيت عناصر نائبة غير مألوفة أو كنت بحاجة للتحقق من الأدوات المتصلة، راجع [CONNECTORS.md](../../CONNECTORS.md).

إنشاء سجل قرار معماري (ADR) أو تقييم تصميم نظام.

## الاستخدام

``` /architecture $ARGUMENTS ```

## الأوضاع

**إنشاء ADR**: "هل يجب أن نستخدم Kafka أو SQS لحافلة الأحداث الخاصة بنا؟" **تقييم التصميم**: "راجع هذا الاقتراح الخاص بالخدمات الدقيقة" **تصميم النظام**: "صمم نظام الإشعارات الخاص بتطبيقنا"

راجع مهارة **system-design** للحصول على إطارات عمل مفصلة حول جمع المتطلبات وتحليل قابلية التوسع وتقييم المقارنات.

## الإخراج — صيغة ADR

```markdown # ADR-[الرقم]: [العنوان]

**الحالة:** مقترح | مقبول | منسوخ | تم استبداله **التاريخ:** [التاريخ] **صناع القرار:** [من يحتاج إلى التوقيع]

## السياق [ما هي الحالة الحالية؟ ما هي القوى التي تعمل؟]

## القرار [ما هو التغيير الذي نقترحه؟]

## الخيارات المدروسة

### الخيار أ: [الاسم] | البعد | التقييم | |-----------|------------| | التعقيد | [منخفض/متوسط/عالي] | | التكلفة | [التقييم] | | قابلية التوسع | [التقييم] | | معرفة الفريق | [التقييم] |

**المميزات:** [قائمة] **العيوب:** [قائمة]

### الخيار ب: [الاسم] [نفس الصيغة]

## تحليل المقارنات [المقارنات الرئيسية بين الخيارات مع التبرير الواضح]

## النتائج المترتبة - [ما يصبح أسهل] - [ما يصبح أصعب] - [ما سيتعين علينا إعادة النظر فيه]

## خطوات العمل 1. [ ] [خطوة التنفيذ] 2. [ ] [المتابعة] ```

## إذا كانت الموصلات متاحة

إذا كانت **قاعدة المعرفة** متصلة: - البحث عن ADRs ومستندات التصميم السابقة - العثور على السياق التقني ذي الصلة

إذا كان **متتبع المشروع** متصلاً: - الربط بالملاحم والتذاكر ذات الصلة - إنشاء مهام التنفيذ

## نصائح

1. **اذكر القيود مقدماً** — "يتعين علينا التسليم في أسبوعين" أو "يجب التعامل مع 10K rps" يشكل الإجابة. 2. **سمِّ خياراتك** — حتى لو كنت تميل بطريقة ما، سأقدم تحليلاً أكثر توازناً مع بدائل واضحة. 3. **ضمّن المتطلبات غير الوظيفية** — زمن الكمون والتكلفة والخبرة والعبء المترتب على الصيانة مهمة بقدر أهمية الميزات.