يعد تحديد مصادر الأحداث ( تحديد مصادر الأحداث ، وتسجيل الأحداث ، وإنشاء الأحداث) نمطًا معماريًا قويًا يتم فيه حفظ جميع التغييرات التي أجريت على حالة التطبيق بالترتيب الذي حدثت به. تعمل هذه السجلات كمصدر للحصول على الحالة الحالية وكتتبع تدقيق لما حدث في التطبيق خلال حياته. يسهل تحديد مصادر الأحداث تغيير البيانات اللامركزية والقراءة. تتسع هذه البنية بشكل جيد وهي مناسبة للأنظمة التي تعمل بالفعل مع معالجة الأحداث أو ترغب في الانتقال إلى مثل هذه البنية.
ما هو مصدر الحدث
يصف خبراء المجال عادةً أنظمتهم على أنها مجموعة من الكيانات ، وهي عبارة عن حاويات لتخزين الحالة والأحداث (الأحداث) التي تعكس التغييرات في الكيانات نتيجة معالجة بيانات الإدخال في عمليات تجارية مختلفة. غالبًا ما يتم تشغيل الأحداث من خلال أوامر من المستخدمين أو عمليات في الخلفية أو عمليات تكامل مع أنظمة خارجية.
بشكل أساسي ، يركز تحديد مصادر الأحداث على الأحداث المتعلقة بالتغييرات في النظام.
ترى العديد من الأنماط المعمارية الكيانات كمفهوم أساسي. تصف هذه القوالب كيفية حفظها ، وكيفية الوصول إليها ، وكيفية تعديلها. ضمن هذا النمط المعماري ، غالبًا ما تكون الأحداث "جانبية": إنها نتائج لتغير الكيانات.
عادةً ما تستند هذه البنى إلى مخزن كيان مثل قاعدة بيانات علائقية أو مخزن مستندات. على الرغم من أن الأحداث قد تكون موجودة في مثل هذه البنية ، إلا أنها ، في جوهرها ، ليست مفهومًا أساسيًا ، ويمكن فصلها عن الكيانات التي ترتبط بها ، وكذلك مخفية خلف طبقات منطق الأعمال.
يعكس "تحديد مصادر الأحداث" هذا النهج من خلال التركيز على تنفيذ الأحداث: كيف يتم استمرارها وكيف يمكن استخدامها للحصول على حالة الكيان. في هذه الحالة ، ستحتوي قاعدة البيانات على سجل تسلسلي لجميع الأحداث التي حدثت أثناء وجود النظام.
فيما يلي مقارنة بين متجر الأحداث ومتجر الكيانات (الموصوف بمزيد من التفصيل أدناه):
تحديد مصادر الأحداث ، باستخدام الأحداث كمفهوم معماري رئيسي ، هو أيضًا نموذج لنمذجة المجال الذي يعكس بشكل أفضل وجهة نظر العميل للنظام. يوفر تصميم الأنظمة مع التركيز على الأحداث وسجلات الأحداث الفوائد التالية:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
دعونا نلقي نظرة على مثال بسيط مع حساب مصرفي. سيكون لدينا كيان يمثل حساب مصرفي. للتبسيط ، سننشئ حسابًا واحدًا فقط دون تحديده باستخدام رقم الحساب أو بأي طريقة أخرى. سيحافظ الحساب على الرصيد الحالي للأموال.
سيتوفر أمران (أمر) للحساب : إيداع الأموال (الإيداع) وسحب الأموال (السحب). ستشير الأوامر إلى المبلغ المراد إيداعه أو سحبه. سنحدد أيضًا قاعدة عمل تتحقق من أنه لا يمكن معالجة أمر السحب إلا إذا كان المبلغ المطلوب مساويًا أو أقل من رصيد الحساب الجاري.
مع هذا النهج ، يمكن تمييز حدثين (حدث)- "حساب مدين" و "حساب مدين". تحتوي هذه الأحداث على معلومات حول المبلغ الذي تم إيداعه أو سحبه. يمكن تبسيط هذا إلى حدث واحد بمجموع موجب أو سالب ، لكن في هذا المثال سنقسمهما.
يوضح الرسم البياني أدناه نموذج البيانات.
لاحظ أن الأحداث "زمن الماضي". تشير إلى ما حدث في النظام وقت كتابتها ، ولا يتم حفظها إلا إذا تمت معالجة الأمر بنجاح. مع هذا النهج ، يجب الحرص على عدم الخلط بين الأوامر والأحداث. خاصة إذا كانت تعكس بعضها البعض.
قد يبدو تسلسل الأوامر كما يلي:
1. إيداع {مبلغ: 100} - إيداع 100
2. سحب {المبلغ: 80} - سحب 80
3. سحب {المبلغ: 50} - سحب 50
يتطلب أبسط تنفيذ لمصادر الأحداث سجل أحداث ، وهو مجرد سلسلة من الأحداث. عند معالجة الأوامر أعلاه ، تحصل على مثل هذا السجل.
لا يمكن تنفيذ الأمر الثالث لأن المبلغ المطلوب يتجاوز الرصيد المتاح.
للحصول على الرصيد الحالي ، يجب على النظام معالجة أو "إنشاء" الأحداث بترتيب حدوثها. على سبيل المثال ، قد يبدو كالتالي:
- الحساب المصرفي {الرصيد الحالي: 0} (حالة البداية)
الحساب المصرفي {الرصيد الحالي: 0} (حالة البداية) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
يتم حساب الرصيد الحالي من خلال معالجة جميع الأحداث حتى اللحظة الحالية. نظرًا لأن لكل حدث طابع زمني ضمني ، فمن الممكن حساب حالة الحساب في أي وقت من خلال معالجة جميع الأحداث للفترة الزمنية المطلوبة.
هذا مثال كامل (وإن كان تافهًا) على مصادر الأحداث. في نظام حقيقي ، من المحتمل أن يحتاج هذا المثال إلى تمديد.
قد يكون من الضروري حفظ تسلسل الأوامر لتتمكن من تحديد كيفية وقوع الحدث ، وكذلك إنشاء سجل أحداث خطأ منفصل لتسجيل الأوامر التي فشلت في إكمالها ، لمزيد من معالجة الأخطاء والحفاظ على سجل كامل للنجاح و فرق فاشلة.
بمرور الوقت ، مع زيادة عدد الأوامر ، قد يكون من الضروري الحفاظ على رصيد الحساب الجاري بحيث عند استلام أمر سحب ، ليس من الضروري معالجة القائمة الكاملة للأحداث لتحديد ما إذا كان يمكن تنفيذ الأمر (أي إذا كان الحساب به أموال كافية). هذا مثال لمتجر مشتق وهو في الأساس نفس متجر الكيانات.
فيما يلي كيف سيبحث متجر الكيانات عن مثالنا بعد معالجة جميع الأوامر.
من الواضح ، مقارنة بمتجر الأحداث الكامل ، أن هذا مثال بدائي للغاية. وهذا أحد أسباب استخدام العديد من المطورين لمتجر الكيانات فقط. في هذه الحالة ، يتوفر رصيد الحساب الجاري على الفور وليس هناك حاجة لمعالجة جميع الأحداث التاريخية.
ومع ذلك ، لا يستبعد Event Sourcing مخازن الكيانات. في كثير من الأحيان ، توجد متاجر الكيانات في مشاريع مصادر الأحداث أيضًا.
نهاية الجزء الأول.
