لماذا يعد Event Sourcing هو المضاد لتفاعل الخدمات الصغيرة

مرحبا مجددا. في مارس ، أطلقت OTUS الدفق التالي من دورة مهندس البرمجيات . تحسبًا لبدء الدورة ، قمنا بإعداد ترجمة لمواد مفيدة لك.




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

أحداث المجال كأساس للغة واحدة


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

تستخدم أحداث المجال للتواصل بين السياقات


يمكن استخدام أحداث المجال للتفاعل بين السياقات المقيدة. لنفترض أن لدينا متجرًا عبر الإنترنت مع ثلاثة سياقات: الطلب (التسليم) ، التسليم (التسليم) ، الفاتورة (الحساب).

ضع في اعتبارك حدث "تم قبول الطلب" في سياق الأمر. يهتم سياق الفاتورة ، وكذلك سياق التسليم ، بتتبع هذا الحدث ، حيث يقوم هذا الحدث بتشغيل بعض العمليات الداخلية في هذه السياقات.

أسطورة الاتصال الضعيف


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

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

إنه أمر رائع ، ولكن الصعوبة تكمن في تحديد البيانات التي سيتم تخزينها في الحدث؟

الجواب البسيط: مصدر الحدث!


الأحداث مفيدة ، فلماذا لا تستخدمها إلى أقصى حد. هذه هي الفكرة الرئيسية لمصدر الأحداث . تقوم بتخزين حالة الوحدة ليس من خلال تحديث بياناتها (CRUD) ، ولكن من خلال استخدام دفق الأحداث.
إلى جانب حقيقة أنه يمكنك تشغيل الأحداث والحصول على الحالة ، هناك ميزة أخرى لـ Event Sourcing: يمكنك الحصول على سجل تدقيق كامل مجانًا. لذلك ، عندما يكون مثل هذا السجل مطلوبًا ، عند اختيار استراتيجية تخزين ، تأكد من الانتباه إلى مصادر الأحداث.

يعد تحديد مصادر الحدث مجرد طبقة تخزين


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

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

إذا كنت تستخدم Event Sourcing على مستوى العالم ، فإنك تكشف عن مستوى التخزين لديك.

تصبح طريقة تخزين البيانات API العامة الخاصة بك. في كل مرة تقوم فيها بإجراء تغييرات على مستوى التخزين ، سيكون عليك التعامل مع تغيير في واجهة برمجة التطبيقات العامة.

أنا متأكد من أن الجميع سيوافق على أن الأمر سيئ عندما تشارك سياقات محدودة مختلفة البيانات في قاعدة بيانات (علائقية) بسبب الاتصال الناتج. ولكن كيف يختلف هذا عن مصدر الأحداث؟ لا شيئ. لا يهم إذا كنت تستخدم الأحداث المشتركة أو الجداول المشتركة في قاعدة البيانات. في كلتا الحالتين ، تشارك تفاصيل التخزين.

هناك مخرج


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

الحل المقترح بسيط للغاية: بغض النظر عن النهج الذي تستخدمه لتخزين البيانات (CRUD أو تحديد مصادر الأحداث) ، فأنت تنشر أحداث النطاق في متجر الأحداث العالمي. تمثل هذه الأحداث واجهة برمجة التطبيقات العامة لسياقك. عند استخدام Event Sourcing ، يمكنك تخزين أحداث Event Sourcing في متجرك المحلي ، ولا يمكن الوصول إليها إلا لهذا السياق المحدود.

حرية الاختيار


يتيح لك وجود أحداث مجال منفصلة في واجهة برمجة التطبيقات العامة تصميمها بمرونة. أنت لا تقتصر على نموذج محدد مسبقًا من خلال مصادر الأحداث.

هناك خياران للعمل مع "الأحداث الواقعية": خدمة بروتوكول مفتوح ولغة عامة (خدمة استضافة مفتوحة ، لغة منشورة) أو عميل / مورد.

الخدمة ببروتوكول مفتوح ولغة عامة (Open Host Service ، لغة منشورة)


يتم نشر حدث مجال واحد فقط يحتوي على كافة البيانات التي قد تحتاجها سياقات محدودة أخرى. في مصطلحات DDD ، يمكن أن يسمى هذا خدمة Host Host ولغة منشورة.



تؤدي بداية الحدث الواقعي "تم قبول الطلب" إلى نشر حدث مجال OrderAccepted واحد . تحتوي حمولة هذا الحدث على جميع بيانات الطلب التي قد تحتاجها سياقات مقيدة أخرى ... لذا نأمل أن تجد سياقات الفاتورة والتسليم جميع المعلومات التي تحتاجها.

العميل / المورد


لكل مستهلك ، يتم نشر أحداث منفصلة. من الضروري تنسيق نماذج كل حدث مع مستهلك واحد فقط ؛ وليس من الضروري تحديد نموذج مشترك مشترك. DDD يسمي هذه العلاقة العميل / المورد.



يؤدي وقوع أحداث واقعية "طلب مقبول" إلى نشر أحداث فردية لكل من المستهلكين: InvoiceOrderAcceptedو DeliveryOrderAccepted. يحتوي كل حدث مجال فقط على البيانات الضرورية لسياق المستلم.

لا أريد مناقشة إيجابيات وسلبيات هذه الأساليب الآن. أريد فقط أن ألفت الانتباه إلى حقيقة أنه يمكنك اختيار عدد أحداث النطاق والبيانات التي يقومون بتخزينها.

هذه ميزة لا يجب الاستهانة بها ، لأنه يمكنك تحديد كيفية تطوير واجهة برمجة التطبيقات الخاصة بالسياق المحدود الخاص بك دون التقيد بأحداث مصادر الأحداث.

استنتاج


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


الترجمة: "مطور جيد مثل بالذئب خائف من الرصاص الفضي."

يعد تحديد مصدر الحدث نهجًا قويًا إذا تم استخدامه بشكل صحيح (محليًا). للوهلة الأولى ، يبدو أنه بالنسبة للهندسة الموجهة نحو الحدث ، هذه رصاصة فضية ، ولكن إذا نظرت عن كثب ، يمكنك أن ترى أن هذا النهج يمكن أن يؤدي إلى اتصال قوي ... وهو بالطبع لا تريده.

المراجع


بالإضافة إلى تجربتي الشخصية ، تلقيت الكثير من الإلهام من مقالات ومؤتمرات مختلفة. أود أن أذكر العرض الذي قدمه Eberhard Wolff "الهندسة والتطبيقات القائمة على الأحداث مع Kafka و Atom" (بنية الحدث والتنفيذ باستخدام Kafka و Atom). خصوصا حول الحدث مصادر و ما هي الأحداث التي يتسم بأهمية كبيرة في سياق هذا المنصب. تم استلهام مثال المتجر عبر الإنترنت أيضًا من هذا الحديث.

إذا كنت تريد المزيد من المعلومات ، يمكنك الرجوع إلى هذه الموارد:


: « : ».

All Articles