منابع: قسمت 1 – کاوش در منابع رویداد در Raku

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

برای تحصیلاتم ، من به راحتی نوشتن یک چارچوب را شروع کردم
اجرای منابع رویداد در Raku. آن را منابع می نامند.

منابع دارای چند مفهوم کلیدی است. در این بخش اول ، ما در مورد سه مورد از آنها بحث خواهیم کرد:

1. وقایع
2. فروشگاه
3. پیش بینی

وقایع

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

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

رویدادها حقایقی را که قبلاً اتفاق افتاده است ضبط می کند ،
به این معنی که آنها یک سابقه قطعی از دولت هستند
انتقال در سیستم شما.

با ضبط هر رویدادی ، شما یک تاریخچه کامل از همه اقدامات ایجاد می کنید ،
ردیابی مسائل یا درک آسانتر
چگونه به یک کشور خاص رسید.

فروشگاه

فروشگاه رویداد یک مکانیزم تخصصی ذخیره سازی برای رویدادها است.
این به عنوان یک منبع حقیقت برای همه تغییرات دولت عمل می کند
در سیستم خود با ارائه این ویژگی ها:

رویدادها به صورت ضمیمه ذخیره می شوند ،
اطمینان از ضبط یک رویداد ،
هرگز اصلاح نمی شود.

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

• دوام و حسابرسی:

فروشگاه رویداد رکورد دائمی از هر رویداد را حفظ می کند ،
که می تواند برای اشکال زدایی ، تجزیه و تحلیل استفاده شود ،
یا حتی بازآفرینی دولت در هر مقطع زمانی معین.

پیش بینی

پیش بینی ها وظیفه تغییر جریان خام را بر عهده دارند
از وقایع در یک مدل خوانده شده که پرس و جو و کار با آن آسان تر است.
بسیاری از پیش بینی ها می توانند/باید از همان مجموعه رویدادها استفاده کنند.
آنها چندین کارکرد مهم را ارائه می دهند:

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

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

با جدا کردن مدل نوشتن (رویدادها) از مدل خوانده شده (پیش بینی ها) ،
می توانید عملکرد و مقیاس پذیری برنامه خود را بهینه کنید.

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

مثال تحویل غذا

برای نشان دادن چارچوب ، بیایید یک سیستم تحویل مواد غذایی ساده بسازیم.
این سیستم از چند نوع رویداد برای نشان دادن متفاوت استفاده می کند
مراحل در چرخه عمر سفارش ، نمونه ای از یکی از کلاس رویدادها
Wold Be:

use Sourcing;
use UUID::V4;

unit event Sourcing::FoodDelivery::Event::OrderCreated;

has Str  $.order-id      = uuid-v4;
has Str  $.delivery-code = (1 ..^ 100)>> .fmt("%02d") .pick;
has UInt $.user-id       is required;
has UInt $.restaurant-id is required;
has Str  %.item{Str};

پیش بینی: تحویل status

پیش بینی ها برای حفظ یک مدل خوانده شده ، رویدادهایی را مصرف می کنند. در این مثال ،
پیش بینی DeliveryStatus وضعیت سفارش و فروشگاه ها را ردیابی می کند
کد تحویل مورد نیاز برای تحویل دهنده.

هنگامی که یک شیء پیش بینی ایجاد می شود ، در یک مدیر ثبت می شود
(برای توصیف در یک پست آینده) و تا زمانی که در حافظه باقی می ماند
بارگیری نشده (یک ویژگی هنوز در حال توسعه است).

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

use Sourcing;
use OrderCreated;
use OrderAccepted;
use DeliveryStarted;
use DeliveryCompleted;
use OrderDelivered;

unit projection Sourcing::FoodDelivery::DeliveryStatus;

has Str      $.order-id    is aggregation-id;
has Str      $.status       = "";
has DateTime $.last-status .= now;
has Str      $.delivery-code;

method summary is query{ :sync } {
    %(
        :$!order-id,
        :$!status,
        :$!last-status,
        :$!delivery-code,
    )
}

multi method apply(OrderCreated $_) {
    $!status        = "placed";
    $!last-status   = .timestamp;
    $!delivery-code = .delivery-code;
}

multi method apply(OrderAccepted $_) {
    $!status        = "preparing";
    $!last-status   = .timestamp;
}

multi method apply(DeliveryStarted $_) {
    $!status      = "collected";
    $!last-status = .timestamp;
}

multi method apply(DeliveryCompleted $_) {
    $!status      = "delivered";
    $!last-status = .timestamp;
}

multi method apply(OrderDelivered $_) {
    $!status      = "done";
    $!last-status = .timestamp;
}

روش اعمال

هر پیش بینی برای هر یک از کاندیداهای روش کاربردی نیاز دارد
رویدادی که قصد رسیدگی دارد. وقتی یک رویداد منتشر می شود ،
طرح ریزی به طور خودکار درخواست مربوطه را فراخوانی می کند
روش به روزرسانی حالت خود بر اساس داده های رویداد.

ویژگی پرس و جو است

روشهای مشخص شده با ویژگی پرس و جو IS در معرض مشتری قرار دارند.
هنگامی که با پارامتر: SYNC مشخص می شود ، این روش ها ابتدا فرآیند
همه وقایع در انتظار ، اطمینان از وضعیت پیش بینی
به روز قبل از بازگشت نتیجه.

مثال استفاده

توجه: اگرچه رویدادها باید از طریق دستورات اختصاصی منتشر شوند ،
برای این مثال ما آنها را مستقیماً منتشر می کنیم.

...

my Sourcing::Client $s          = Sourcing::Client.new;
$s.register-class: "DeliveryStatus";
my RedEventStore::Client $store = RedEventStore::Client.new, 
my \DeliveryStatus              = $s.get-class-client("DeliveryStatus");

sub emit-event(Sourcing::Event $event, :$order) {
    say "{ gray $event.timestamp.hh-mm-ss }: emitting the event: { yellow $event.^shortname }";

    $store.add-event: $event;
    given $order.summary {
        say "Current state: STATUS: { green . }; CODE: { green . }"
    }
    sleep 1
}

sub MAIN(Str :$order-id = uuid-v4) {
    say "Using order-id: { red $order-id }";

    my $order           = DeliveryStatus.new: :$order-id;
    my $user-id         = ^10 .pick;
    my $restaurant-id   = ^10 .pick;
    my $prepare-minutes = 10;
    my $deliverer-id    = ^10 .pick;

    emit-event :$order, OrderCreated.new:      :$order-id, :$user-id, :$restaurant-id;
    emit-event :$order, PaymentInitiated.new:  :$order-id, :payment-data;
    emit-event :$order, PaymentConfirmed.new:  :$order-id;
    emit-event :$order, OrderAccepted.new:     :$order-id, :$restaurant-id, :$prepare-minutes;
    emit-event :$order, DeliveryStarted.new:   :$order-id, :$deliverer-id;
    emit-event :$order, DeliveryCompleted.new: :$order-id, :delivery-code("10");
    emit-event :$order, OrderDelivered.new:    :$order-id;
}

با اجرای این کار ، چیزی شبیه به این را چاپ می کند:

طرح ریزی: user -orders

یک طرح ساده دیگر که می توانیم در اینجا استفاده کنیم یک طرح ریزی خواهد بود
برای نشان دادن تمام سفارشات یک کاربر. این به سادگی یک واحد خواهد بود
نوع رویداد
متفاوت از اولین پیش بینی که حوادث را جمع می کند
با استفاده از Order-ID ، UserOrders از User-ID به عنوان جمع آوری ID استفاده می کند
برای گروه بندی همه رویداد “از” همان کاربر با هم.
(من قصد دارم ، در بعضی از مواقع ، نقشه برداری از ویژگی های رویداد را امکان پذیر کنم
با نام های مختلف به عنوان یک جمع در پیش بینی ها).

use Sourcing;
use OrderCreated;

unit projection Sourcing::FoodDelivery::UserOrders;

has Str $.user-id is aggregation-id;
has Str @.orders;

method users-orders is query {
    @!orders
}

multi method apply(OrderCreated $_) {
    @!orders.push: .order-id
}

پایان

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