Martin Fowler، منبع رویداد را که یک الگوی معماری است، به صورت زیر تعریف می کند:
«ثبت تمام تغییرات در وضعیت یک اپلیکیشن به صورت دنباله ای از رویداد ها»
برای این کار، از ابزار های مختلفی می توان استفاده کرد که روش انتخابی، باید متناسب با معماری نرم افزار و تکولوژی های مورد استفاده در آن، باشد. (این که از چه نوع پایگاه داده و مدلی برای ثبت تغییرات وضعیت نرم افزار استفاده کنیم.) نکته مهم در این زمینه، پیوستگی دیتای ثبت شده است؛ به این معنی که ثبت دیتا باید به گونه ای باشد که مسیر تغییر رفتارها قابل مشاهده و قابل تحلیل باشد.
باید بتوان تشخیص داد که دقیقا در چه مرحله ای رفتار و عملکرد نرم افزار، اشتباه و غیر قابل انتظار بوده است. ES فواید زیادی دارد که از جمله مهمترین آن ها می توان به دیباگ منطقی پروژه و کنترل کیفی و رفتاری آن اشاره کرد.
به عنوان مثال، در سامانه های مالی که به طور مستقیم با محاسبات مالی و پولی ارتباط دارند، پیاده سازی چنین فرایندی برای دنبال کردن مقادیر مالی و کشف کسورات در انتهای محاسبات و گزارشات، به شدت حائز اهمیت است. همچنین زمانی که یک نسخه جدید از پروژه ارائه می شود، انتظار می رود که تغییرات اعمال شده روی آن نسبت به نسخه قبلی، در رفتار پروژه نیز دیده شود که در این موارد، از منبع رویداد و مقایسه دیتای ضبط شده می توان استفاده کرد.
ایده اساسی Event Sourcing این است که اطمینان حاصل شود هر تغییری که در وضعیت برنامه کاربردی ایجاد می شود، در یک شی رویداد ثبت می شود و این اشیاء رویداد، خودشان به ترتیب وقوع رویداد ها و به طور قابل بازگشت، در پایگاه داده ثبت می شوند.
بیایید یک مثال ساده برای انجام اعلان های حمل و نقل در نظر بگیریم. در این مثال ما کشتی های زیادی در دریاهای آزاد داریم و باید بدانیم هر یک کجا هستند؛ یک راه ساده برای انجام این کار، داشتن یک برنامه کاربردی ردیابی با روش هایی است که به ما امکان می دهد بفهمیم کشتی چه زمانی به بندر می رسد و یا حرکت می کند.
در این حالت، زمانی که سرویس فراخوانی می شود، کشتی مربوطه را پیدا کرده و مکان آن را به روز می کند. اشیاء کشتی، وضعیت شناخته شده فعلی کشتی ها را ثبت می کنند.
معرفی Event Sourcing یک مرحله به این فرآیند اضافه می کند. اکنون این سرویس یک شی رویداد ایجاد می کند تا تغییر را ثبت کند و آن را برای به روز رسانی کشتی پردازش می کند.
با نگاه به شکل بالا، شاید احساس کنیم که یک گام بیهوده به پروسه اضافه شده است. اما وقتی از بیرون (out of box) به آن نگاه کنیم، متوجه می شویم که چقدر دقت کاری نرم افزار، ارتقاء یافته است؛ طوری که کوچکترین تغییرات هم در این مدل، قابل پیگیری و کنترل هستند. فرض کنید:
اگر از منابع رویداد استفاده نکنیم، فقط وضعیت آخر هر کشتی را در اختیار خواهیم داشت. در صورتی که با استفاده از منابع رویداد، دقیقا متوجه می شویم که زمانی که X در یک مکان خاص بوده است، Y کجا بوده است و تمام این تغییرات و رویداد ها، دقیقا ثبت و نگهداری شده اند.
الگوی معماری Event Sourcing یا به طور مختصر ES، یک روش متفاوت برای Data storage می باشد.
اکثرا ما از Data store هایی که مدلی از دیتا را انعکاس میدهند استفاده می کنیم. ES از برنامه نویسان می خواهد که مدل سنتی CRUD را فراموش کرده و به جای آن، تغییراتی را که روی دیتا صورت گرفته، نیز درج نمایند. اینکار به وسیلهی یک دیتابیس Append-only انجام می شود که با نام Event Store شناخته می شود.
در این معماری، همهی تغییرات اعمال شده روی دیتا، به صورت رویداد های پشت سرهم و ترتیب دار و در قالب یک حالت از سیستم، ذخیره می شوند که بعدا می توان در صورت نیاز، به حالت های قبلی سیستم و object ها دسترسی پیدا کرد.
این الگو برای پیدا کردن وضعیت گذشته یک شی کمک بزرگی می کند و این فرایند را تسهیل می بخشد؛ علاوه بر فواید ذکر شده، می توان از منبع رویداد به عنوان یک Logger استفاده نمود. به دلیل اینکه جز به جز تغییرات اعمال شده بر روی state سیستم، در آن ثبت شده است. از آنجایی که دیتا بصورت serialized ذخیره می شود، بارگذاری آن نیز با سرعت بالایی انجام خواهد شد.
«این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است.»
https://martinfowler.com/eaaDev/EventSourcing.html
https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing