Event Sourcing

همانطور که می دانیم اکثر برنامه ها داده ها را با وضعیت فعلی موجود در پایگاه داده ذخیره می کنند. به عنوان مثال، اگر کاربر آدرس ایمیل را به برنامه ما تغییر دهد، فیلد ایمیل کاربر با آدرس جدید به روز می شود. بنابراین اطلاعات ایمیل فیلد موجود ایمیل در جدول کاربر را نادیده می گیرد. به این ترتیب ما همیشه آخرین وضعیت داده ها را می دانیم. با استفاده از الگوی منبع یابی رویداد، به عملیات ذخیره داده در پایگاه داده تغییر می کند. به جای ذخیره آخرین وضعیت داده ها در پایگاه داده، الگوی منبع یابی رویداد ذخیره همه رویدادها را در پایگاه داده با ترتیب متوالی رویدادهای داده ارائه می دهد. این پایگاه داده رویدادها به نام فروشگاه رویداد.

به جای به روز رسانی وضعیت یک رکورد داده، هر تغییر را به لیست متوالی رویدادها اضافه می کند. بنابراین فروشگاه رویداد به منبع حقیقت برای داده ها تبدیل می شود. پس از آن، این رویداد ذخیره می شود به پایگاه داده خواندن با پیروی از الگوی views materialized تبدیل.

این عملیات تبدیل می تواند با الگوی انتشار/اشتراک با انتشار رویداد با سیستم های کارگزار پیام انجام شود. همچنین این لیست رویداد امکان پخش مجدد رویدادها را در مُهر زمانی معین می دهد و از این طریق می تواند آخرین وضعیت داده ها را بسازد.

الگو Event Sourcing چه زمانی از این الگو استفاده کنیم؟

از این الگو در سناریوهای زیر استفاده کنید:

زمانی که می خواهید قصد، هدف یا دلیل را در داده ها ثبت کنید. به عنوان مثال، تغییرات یک موجودیت مشتری را می توان به عنوان یک سری از انواع رویدادهای خاص، مانند خانه منتقل شده، حساب بسته، یا متوفی ثبت کرد.

زمانی که به حداقل رساندن یا کاملاً اجتناب از بروز به روز رسانی متناقض داده ها حیاتی است.

هنگامی که می خواهید رویدادهایی را که رخ می دهند ضبط کنید، آنها را دوباره پخش کنید تا وضعیت یک سیستم بازیابی شود، تغییرات را به عقب برگردانید، یا سابقه و گزارش حسابرسی را نگه دارید. به عنوان مثال، هنگامی که یک کار شامل چندین مرحله است، ممکن است لازم باشد اقداماتی را برای بازگرداندن به‌روزرسانی‌ها انجام دهید و سپس برخی از مراحل را مجدداً پخش کنید تا داده‌ها به حالت ثابت بازگردند.

وقتی از رویدادها استفاده می کنید. این یک ویژگی طبیعی عملکرد برنامه است و به توسعه یا تلاش اضافی کمی نیاز دارد.

زمانی که نیاز دارید فرآیند ورودی یا به‌روزرسانی داده‌ها را از وظایفی که برای اعمال این اقدامات لازم است جدا کنید. این تغییر ممکن است برای بهبود عملکرد رابط کاربری یا توزیع رویدادها به سایر شنوندگانی باشد که هنگام وقوع رویدادها اقدامی انجام می دهند. به عنوان مثال، می توانید یک سیستم حقوق و دستمزد را با یک وب سایت ارسال هزینه ها ادغام کنید. رویدادهایی که توسط فروشگاه رویداد در پاسخ به به روز رسانی داده های ایجاد شده در وب سایت مطرح می شود، هم توسط وب سایت و هم سیستم حقوق و دستمزد مصرف می شود.

هنگامی که می‌خواهید انعطاف‌پذیری را داشته باشید تا بتوانید قالب مدل‌های تحقق‌یافته و داده‌های موجود را در صورت تغییر نیازمندی‌ها تغییر دهید، یا - وقتی با CQRS استفاده می‌شود - باید یک مدل خوانده شده یا نماهایی را که داده‌ها را نشان می‌دهند تطبیق دهید.

هنگامی که با CQRS استفاده می شود، سازگاری نهایی قابل قبول است در حالی که یک مدل خوانده شده به روز می شود، یا تأثیر عملکرد موجودات و داده های آبرسانی مجدد از یک جریان رویداد قابل قبول است.

این الگو ممکن است در شرایط زیر مفید نباشد:

دامنه‌های کوچک یا ساده، سیستم‌هایی که منطق تجاری کمی دارند یا اصلاً منطقی ندارند، یا سیستم‌های غیردامنه‌ای که طبیعتاً با مکانیزم‌های مدیریت داده‌های سنتی CRUD به خوبی کار می‌کنند.

سیستم‌هایی که در آنها به‌روزرسانی‌های بی‌درنگ و سازگاری برای نماهای داده‌ها مورد نیاز است.

سیستم‌هایی که در آن مسیرهای حسابرسی، سابقه و قابلیت‌هایی برای بازگرداندن و پخش مجدد اقدامات لازم نیست.

الگو Event Sourcing یک الگوی طراحی معماری است که داده ها را در یک گزارش فقط ضمیمه ذخیره می کند. این بخشی از یک اکوسیستم گسترده‌تر از الگوهای طراحی است که به روش‌های مختلف با هم کار می‌کنند تا به توسعه‌دهندگان اجازه دهند مؤثرترین معماری را برای نیازهای خود ایجاد کنند.

منابع :

https://www.eventstore.com/event-sourcing#:~:text=What%20is%20Event%20Sourcing%3F,the%20same%20piece%20of%20information.