اقرأ الجزء الأول.
ميزات تنفيذ "مصادر الأحداث"
من وجهة نظر فنية ، لا يتطلب "تحديد مصادر الأحداث" سوى تنفيذ تسجيل الأحداث وتسجيلها.
في أبسط الحالات ، يمكن استخدام ملف كمخزن للأحداث ، حيث يتم تسجيل حدث منفصل في كل سطر ، أو عدة ملفات ، عند حفظ كل حدث في ملف منفصل. ولكن كقاعدة عامة ، في الأنظمة الكبيرة التي تتطلب التوازي وقابلية التوسع ، يتم استخدام طرق تخزين أكثر موثوقية.
سجل الأحداث هو نمط شائع جدًا يستخدم مع وسيط الرسائل (البرامج الوسيطة الموجهة للرسائل) وأنظمة معالجة تدفق الأحداث. يمكن لوسيط الرسائل ، المستخدم كسجل أحداث ، تخزين محفوظات الرسائل بالكامل إذا لزم الأمر.
تركز النماذج العلائقية والوثائقية عادةً على نمذجة الكيانات. في مثل هذه النماذج ، من السهل الحصول على الحالة الحالية من خلال قراءة سطر واحد أو أكثر أو وثيقة. تجدر الإشارة إلى أن "مصادر الأحداث" والنموذج العلائقي لا يستبعد أحدهما الآخر. غالبًا ما تتضمن أنظمة تحديد مصادر الأحداث كلاهما. يتمثل الاختلاف الرئيسي مع Event Sourcing في أن مخزن الكيان لم يعد يُعامل كبيانات أولية. يمكن استبداله أو إعادة بنائه من خلال إعادة معالجة سجل الأحداث.
في أنظمة تحديد مصادر الأحداث الأكثر تعقيدًا ، يجب أن تكون مخازن الحالة المشتقة موجودة لطلبات القراءة الفعالة ، نظرًا لأن الحصول على الحالة الحالية من خلال معالجة سجل الأحداث بالكامل بمرور الوقت يمكن أن يتوقف عن القياس. يمكن استخدام كل من قواعد البيانات العلائقية والوثيقة كسجل أحداث وكمستودع للكيانات المشتقة ، والتي يمكنك من خلالها الحصول بسرعة على الحالة الحالية. في الواقع ، هذا التقسيم للمهام هو CQRS (فصل مسؤولية استعلام القيادة ، تقسيم المسؤولية إلى أوامر واستفسارات). يتم توجيه جميع الطلبات إلى المخزن المشتق بحيث يمكن تحسينها بغض النظر عن عمليات الكتابة.
بصرف النظر عن الجزء الفني ، هناك نقاط أخرى تستحق الاهتمام بها.
قضايا مصادر الأحداث المحتملة
على الرغم من مزايا "تحديد مصادر الأحداث" ، إلا أن لها عيوبًا أيضًا.
عادة ما تكون أكبر التحديات في عقلية المطورين. يحتاج المطورون إلى تجاوز تطبيقات CRUD التقليدية ومخازن الكيانات. يجب أن تصبح الأحداث الآن المفهوم الرئيسي.
مع Event Sourcing ، يتم إنفاق الكثير من الجهد على أحداث النمذجة. بعد كتابة الأحداث في السجل ، يجب اعتبارها دون تغيير ، وإلا فقد يكون التاريخ والحالة تالفين أو فاسدين. سجل الأحداث هو البيانات الأولية ، مما يعني أنك بحاجة إلى توخي الحذر الشديد للتأكد من احتوائه على جميع المعلومات اللازمة للحصول على الحالة الكاملة للنظام في وقت معين. يجب أيضًا أن يوضع في الاعتبار أنه يمكن إعادة تفسير الأحداث حيث يتغير النظام (والعمل الذي يمثله) بمرور الوقت. ولا تنسى الأحداث الخاطئة والمشبوهة مع المعالجة الصحيحة للتحقق من صحة البيانات.
بالنسبة لنماذج المجال البسيطة ، يمكن أن يكون هذا التغيير في التفكير سهلاً للغاية ، ولكن بالنسبة لنماذج المجال الأكثر تعقيدًا ، يمكن أن يكون مشكلة (خاصة مع الكثير من التبعيات والعلاقات بين الكيانات). قد يكون من الصعب التكامل مع الأنظمة الخارجية التي لا توفر البيانات في وقت معين.
يمكن أن يعمل تحديد مصادر الأحداث بشكل جيد على الأنظمة الكبيرة لأن نمط سجل الأحداث يتدرج بشكل أفقي. على سبيل المثال ، لا يلزم أن يتواجد سجل الأحداث لكيان ما فعليًا مع سجل الأحداث لكيان آخر. ومع ذلك ، فإن سهولة القياس تؤدي إلى مشاكل إضافية في شكل معالجة غير متزامنة وفي النهاية بيانات متسقة. يمكن أن تأتي أوامر تغيير الحالة إلى أي عقدة ، وبعد ذلك يحتاج النظام إلى تحديد العقد المسؤولة عن الكيانات المقابلة وإرسال الأمر إلى هذه العقد ، ثم معالجة الأمر ، ثم نسخ الأحداث التي تم إنشاؤها إلى العقد الأخرى حيث يتم تخزين سجلات الأحداث. وفقط بعد اكتمال هذه العملية ، يصبح الحدث الجديد متاحًا كجزء من حالة النظام.وبالتالي ، يتطلب "تحديد مصادر الأحداث" في الواقع أن تكون معالجة الأمر منفصلة عن طلب الحالة ، أي CQRS.
لذلك ، تحتاج أنظمة تحديد مصادر الأحداث إلى مراعاة الفاصل الزمني بين إصدار الأمر وتلقي إشعار حول تسجيل الأحداث بنجاح. قد تكون حالة النظام التي يراها المستخدمون في هذا الوقت "خاطئة". أو بالأحرى ، قديمة بعض الشيء. لتقليل تأثير هذا العامل ، من الضروري أخذه في الاعتبار عند تصميم واجهة المستخدم وفي المكونات الأخرى. من الضروري أيضًا التعامل بشكل صحيح مع المواقف عندما يفشل أحد الأوامر أو يتم إلغاؤه أثناء التنفيذ أو يتم استبدال حدث واحد بأحدث عند تحديث البيانات.
ستنشأ مشكلة أخرى عندما تتراكم الأحداث بمرور الوقت وسيكون من الضروري العمل معها. إن مجرد كتابتها بعد المعالجة شيء ، والعمل مع السجل بالكامل شيء آخر. بدون هذه الوظيفة ، يفقد سجل الأحداث قيمته تمامًا. هذا ينطبق بشكل خاص على التعافي من الكوارث أو عند ترحيل المخازن المشتقة ، عندما قد تحتاج جميع الأحداث إلى إعادة المعالجة لتحديث البيانات. بالنسبة للأنظمة التي بها عدد كبير من الأحداث ، يمكن أن تتجاوز إعادة معالجة السجل بأكمله وقت الاسترداد المسموح به. هذا هو المكان الذي يمكن أن تساعد فيه لقطات النظام الدورية حتى تتمكن من البدء في التعافي من حالة صحية لاحقة.
من الضروري أيضًا النظر في بنية الأحداث. يمكن أن يتغير هيكل الأحداث بمرور الوقت. مجموعة الحقول قد تتغير. قد تكون هناك مواقف تحتاج فيها الأحداث القديمة إلى المعالجة بواسطة منطق الأعمال الحالي. وسيساعد وجود مخطط حدث قابل للتوسيع في المستقبل ، إذا لزم الأمر ، على تمييز الأحداث الجديدة عن الأحداث القديمة. تساعد اللقطات الدورية أيضًا في عزل التغييرات الرئيسية في بنية الأحداث.
الاستنتاجات
يعد تحديد مصادر الأحداث نهجًا قويًا له فوائد. أحدها هو تسهيل توسيع النظام في المستقبل. نظرًا لأن سجل الأحداث يخزن جميع الأحداث ، فيمكن استخدامها في أنظمة خارجية. من السهل إلى حد ما التكامل عن طريق إضافة معالجات أحداث جديدة.
ومع ذلك ، كما هو الحال مع أي قرار معماري كبير ، يجب أن تكون حريصًا للتأكد من أنه يعمل وفقًا لموقفك. القيود المتعلقة بتعقيد المجال ، ومتطلبات اتساق البيانات وتوافرها ، بالإضافة إلى الزيادة في حجم البيانات المخزنة وقابلية التوسع على المدى الطويل ، يجب مراعاة كل هذه القيود (وهذه ليست بأي حال قائمة شاملة). من المهم بنفس القدر الانتباه إلى المطورين الذين سيقومون بتطوير وصيانة مثل هذا النظام طوال دورة حياته بأكملها.
وأخيرًا ، لا تنس أهم مبدأ في هندسة البرمجيات - حاول أن تبقي كل شيء بسيطًا قدر الإمكان (مبدأ KISS).
