في عالم تطوير البرمجيات السريع، غالبًا ما يكون السياق هو أول ضحية. نتخذ قرارات معمارية حاسمة يوميًا—مثل اختيار قاعدة بيانات، أو اعتماد إطار عمل، أو تصميم بنية API—لكننا نادرًا ما نسجل السبب وراء تلك القرارات. عندما ينضم عضو جديد إلى الفريق، أو عندما تعود إلى مشروع بعد ستة أشهر، تضيع النية الأصلية وراء هذه القرارات. هذا هو المكان الذي تدخل فيه سجلات قرارات البنية (ADRs).
ADRs هي طريقة خفيفة وموحدة لتوثيق القرارات المعمارية المهمة. إنها ليست وثائق تصميم شاملة؛ بل هي إدخالات موجزة وغير قابلة للتغيير تلتقط السياق، والقرار المتخذ، والعواقب المترتبة على ذلك الاختيار. من خلال دمج ADRs في مستودعك، تنشئ تاريخًا قابلًا للتدقيق لتطور نظامك، مما يقلل من إرهاق النقاشات ويوفر وضوحًا للمصممين المستقبليين.
لماذا نستخدم ADRs؟
الفائدة الرئيسية من ADRs هي تقليل "ديون القرارات". بدون توثيق، غالبًا ما يعيد الفرق النظر في نفس الأسئلة المعمارية مرارًا وتكرارًا، مما يؤدي إلى تطبيقات غير متسقة وهدر للوقت. توفر ADRs مصدرًا واحدًا للحقيقة للقرارات السابقة. إذا أراد عضو في الفريق تغيير قرار سابق، يجب عليه أولاً الإشارة إلى ADR، والإقرار بقيوده، واقتراح سجل قرار جديد ليحل محل القديم. هذا ينشئ هيكل حوكمة طبيعي يشجع على إدارة التغيير المدروسة دون عبء عمليات طلب التغيير الرسمية.
علاوة على ذلك، تعمل ADRs كمادة تدريبية. يمكن للمطورين الجدد قراءة تسلسل القرارات لفهم المنطق وراء البنية الحالية، مما يحول ما كان قد يكون صندوقًا أسود إلى نظام شفاف.
هيكل ADR
على الرغم من عدم وجود تنسيق واحد مفروض لـ ADRs، إلا أن الهيكل المعتمد على نطاق واسع يتضمن الأقسام التالية:
- العنوان: وصف قصير وواضح للقرار.
- الحالة: مقترح، مقبول، منسوخ، أو ملغي.
- السياق: بيان المشكلة والقيود. ما هي القوى التي تقود نحو اتخاذ قرار؟
- القرار: التغيير الذي سنقوم به وتفاصيل القرار.
- العواقب: السياق الناتج، بما في ذلك كيف يجعل الأمور أفضل أو أسوأ، وما المشكلات التي قد يسببها في المستقبل.
إليك مثال عملي لـ ADR مكتوب بصيغة Markdown، مخزن في مجلد docs/adr/ داخل مستودعك:
# 001 - اعتماد بنية موجهة بالأحداث لمعالجة الطلبات
## الحالة
مقبول
## السياق
مع نمو حجم طلباتنا، أصبحت واجهة REST الأحادية عنق زجاجة أثناء الأحمال الذروية. المعالجة المتزامنة لفحص الدفع والمخزون تسبب انتهاء المهلة. نحتاج إلى حل يمكنه التعامل مع التزامن العالي وفصل خدماتنا.
## القرار
سنقوم بنقل تدفق معالجة الطلبات إلى بنية موجهة بالأحداث باستخدام Kafka. سننشر حدث `OrderCreated`، وسيتعامل مستهلكون منفصلون مع التحقق من الدفع وحجز المخزون.
## العواقب
**إيجابية:**
- تحسين قابلية التوسع أثناء الأحمال الذروية.
- فصل الخدمات يسمح بالنشر المستقل.
**سلبية:**
- زيادة التعقيد التشغيلي بسبب صيانة Kafka.
- اتساق البيانات هو اتساق نهائي، مما يتطلب التعامل مع إعادة المحاولة والقدرة على التكرار في المستهلكين.
أفضل الممارسات للتنفيذ
لضمان بقاء ADRs الخاصة بك مفيدة، اتبع هذه الممارسات الفضلى:
- اجعلها غير قابلة للتغيير: بمجرد قبول ADR، لا تعدلها. إذا تغير القرار، أنشئ ADR جديدًا يحل محل القديم. هذا يحافظ على التاريخ.
- اجعلها قصيرة: يجب أن يكون ADR قابلاً للقراءة في أقل من دقيقتين. إذا أصبح طويلاً جدًا، فهو وثيقة تصميم، وليس سجل قرار.
- خزنها في نظام التحكم بالإصدارات: وضع ADRs في مستودع Git الخاص بك يضمن أنها مُصنفة جنبًا إلى جنب مع الكود، مما يسهل رؤية متى تم اتخاذ قرار مقارنة بتغييرات الكود.
- استخدم تسلسلًا مرقمًا: رقّم ADRs الخاصة بك (مثل
001-initial-db-choice.md،002-api-versioning.md) للحفاظ على ترتيب زمني واضح.
الخاتمة
سجلات قرارات البنية هي استثمار صغير بعائد مرتفع. فهي تحول المعرفة الضمنية إلى توثيق صريح، مما يعزز ثقافة الوضوح والمساءلة. من خلال اعتماد ADRs، تمكّن فريقك من اتخاذ قرارات مستنيرة، وتقليل النقاشات المكررة، وبناء برمجيات أسهل في الفهم والصيانة مع مرور الوقت. ابدأ صغيرًا: وثّق اختيارك المعماري الكبير التالي، وشاهد كيف تتراكم الفوائد.