ما هو نمط event sourcing، وكيف يعمل؟

نمط event sourcing نمط معماري يركز على تخزين تغييرات الحالة كتسلسل من الأحداث بدلًا من تخزين الحالة الحالية مباشرة. وهذا يعني أن كل تغيير على حالة النظام يُسجَّل كحدث منفصل، ما يوفر تاريخًا مفصلًا لجميع التغييرات.

ومن المبادئ الأساسية لنمط event sourcing أن الأحداث غير قابلة للتغيير ولا يمكن إلا إلحاقها بتدفق الأحداث، ولا تُغيَّر أو تُحذف أبدًا. وهذا يضمن وجود تاريخ كامل ودقيق لجميع تغييرات الحالة دائمًا، وهو ما قد يكون لا يُقدَّر بثمن لتصحيح الأخطاء والتدقيق وإعادة تشغيل حالة النظام.

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

ومقارنة بالأساليب التقليدية لإدارة الحالة، حيث لا تُخزَّن إلا الحالة الحالية، يوفر event sourcing طريقة أكثر تفصيلًا ومرونة للتعامل مع البيانات، لا سيما في الأنظمة المعقدة حيث يُعدّ فهم التغييرات التاريخية أمرًا حاسمًا.

نمط event sourcing نمط معماري يختلف اختلافًا كبيرًا عن نماذج قواعد البيانات التقليدية بتخزين جميع التغييرات على حالة النظام كتسلسل من الأحداث. فبدلًا من تخزين الحالة الحالية للبيانات، كما في عمليات CRUD (Create, Read, Update, Delete) التقليدية، يسجّل event sourcing كل تغيير يقع بمرور الوقت. وهذا يعني أنه يمكن إعادة إنشاء أي حالة سابقة بإعادة تشغيل تاريخ الأحداث من البداية.

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

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

يقدم event sourcing مزايا كبيرة من حيث سلامة البيانات والتاريخ بتخزين كل تغيير على حدة على حالة التطبيق كتسلسل من الأحداث. فبدلًا من تحديث قاعدة بيانات بالحالة الحالية، يسجّل event sourcing كل تغيير، ما يضمن أن تكون جميع تغييرات البيانات قابلة للتتبع بالكامل وإعادة إنتاجها بدقة.

ويوفر هذا النهج تاريخًا شاملًا لجميع التغييرات، ما يتيح إعادة إنشاء الحالات السابقة للنظام بإعادة تشغيل الأحداث بالترتيب الذي وُلِّدت به. وهذا مفيد بشكل خاص عندما يلزم فهم كيفية الوصول إلى حالة معينة، أو عندما يلزم تصحيح الأخطاء؛ ويتم ذلك بإلحاق أحداث تعويضية جديدة بدلًا من حذف القديمة.

ومقارنة بنماذج قواعد البيانات التقليدية، حيث لا تُخزَّن إلا الحالة الحالية، يقدم event sourcing حلًا أكثر متانة لسلامة البيانات. فبالحفاظ على تاريخ كامل للأحداث، يضمن النظام ألا تضيع أي معلومات تاريخية وأن تكون جميع التغييرات قابلة للتحقق والتدقيق، وهو أمر حاسم للتطبيقات التي تتطلب موثوقية عالية وقابلية للتتبع.

يستطيع event sourcing تحسين قابلية التطبيق للتوسع بتغيير طريقة التعامل مع البيانات وتخزينها. فبدلًا من تخزين الحالة الحالية للبيانات، يخزن event sourcing جميع التغييرات كتسلسل من الأحداث. ولأن عمليات الكتابة مجرد إلحاقات بسيطة بسجل، فقد يقلل ذلك الحاجة إلى المعاملات المعقدة وأقفال قواعد البيانات، ما يتيح توسيع جانب الكتابة بكفاءة أكبر.

كما يستطيع event sourcing تحسين قابلية التوسع بإتاحة معالجة الأحداث بالتوازي. إذ يمكن معالجة الأحداث التي تخص كيانات مختلفة بشكل غير متزامن وتوزيعها على عدة خوادم، بينما يجب التعامل مع أحداث الكيان نفسه بالترتيب. وهذا يقلل الحمل على أي خادم منفرد ويحسّن الأداء العام للتطبيق، ما يتيح له التعامل مع كميات أكبر من البيانات ومزيد من المستخدمين المتزامنين دون التفريط في السرعة أو الموثوقية.

ومقارنة بنماذج قواعد البيانات التقليدية، التي كثيرًا ما تتطلب عمليات معقدة ومستهلكة للموارد لتحديث البيانات وصيانتها، يقدم event sourcing حلًا أكثر قابلية للتوسع. فبالتركيز على الأحداث بدلًا من الحالة، يمكن تكييف التطبيق وتوسيعه بسهولة أكبر، ما يجعله مناسبًا جيدًا للأنظمة الموزعة الحديثة التي تتطلب توافرًا وأداءً عاليين.

يوفر event sourcing تاريخًا كاملًا، لكنه يأتي أيضًا بمتطلبات. فحساب الحالة الحالية من أحداث كثيرة قد يستغرق وقتًا، ولهذا كثيرًا ما تُستخدم اللقطات لتخزين الحالة في لحظات معينة.

وقد يكون من الصعب تغيير بنية الأحداث بعد أن يعمل النظام لفترة، لأن الأحداث القديمة لا تزال بحاجة إلى أن تكون قابلة للقراءة. وتتطلب الاستعلامات عبر البيانات عادةً نماذج قراءة منفصلة تُحدَّث بشكل غير متزامن، فقد تكون البيانات قديمة لفترة وجيزة. كما أن طريقة التفكير هذه جديدة على كثير من المطورين، وقد يتطلب حذف البيانات الشخصية حلولًا خاصة، مثل crypto-shredding، حيث يُحذف مفتاح التشفير الخاص ببيانات الشخص.

عند الجمع بين event sourcing و CQRS (Command Query Responsibility Segregation)، يكون ثمة فصل واضح بين الأوامر التي تغيّر الحالة والاستعلامات التي تقرأ الحالة. ويتيح هذا الفصل تحسين كل جزء وتوسيعه باستقلالية، ما يمكن أن يحسّن أداء النظام وقابليته للتوسع.

في معمارية CQRS مع event sourcing، تُعالَج الأوامر بإنشاء أحداث جديدة تصف التغييرات في النظام. وتُخزَّن هذه الأحداث في مخزن أحداث يعمل مصدرًا وحيدًا للحقيقة. وعندما يُخزَّن حدث جديد، يمكن استخدامه لتحديث نماذج القراءة المحسّنة للاستعلامات. وعادةً ما تُحدَّث نماذج القراءة بشكل غير متزامن، ولذلك تكون متسقة في النهاية، ما يعني أنها قد تتأخر قليلًا عن أحدث التغييرات.

ومقارنة بمعماريات CRUD التقليدية، حيث كثيرًا ما تكون تغييرات البيانات والاستعلامات مترابطة بإحكام، يوفر الجمع بين event sourcing و CQRS حلًا أكثر مرونة ومتانة. ذلك أن الأنظمة القائمة على الأحداث تستطيع التعامل مع منطق الأعمال المعقد وتتبع التاريخ بفعالية أكبر مع دعم المعالجة غير المتزامنة وقابلية التوسع. ويُعدّ هذا الجمع مفيدًا بشكل خاص في الأنظمة التي تتطلب توافرًا عاليًا وتحديثات شبه فورية، مثل التطبيقات المالية ومنصات إنترنت الأشياء.