Advanced Patterns: CQRS & Event Sourcing

ရည်ရွယ်ချက်

ရှုပ်ထွေးတဲ့ System တွေမှာ သုံးလေ့ရှိတဲ့ အဆင့်မြင့် Pattern နှစ်ခုဖြစ်တဲ့ CQRS နဲ့ Event Sourcing အကြောင်းကို ခင်ဗျားတို့ လေ့လာရပါမယ်။

CQRS: ရေးတဲ့အပိုင်းနဲ့ ဖတ်တဲ့အပိုင်းကို ခွဲထုတ်ခြင်း

Application အများစုမှာ Data ကို Database ထဲ ထည့်တာ (Write) ရော၊ ပြန်ဖတ်တာ (Read) ကိုပါ Model တစ်ခုတည်းကနေပဲ လုပ်လေ့ရှိပါတယ်။

ဒါပေမဲ့ ပြဿနာက Data ကို Write လုပ်တဲ့အခါ Business Rule တွေ အများကြီးစစ်ဆေးဖို့ လိုပြီး ရှုပ်ထွေးတတ်ပါတယ်။ ဖတ်တဲ့ (Read) အခါကျတော့ User ကို မြန်မြန်ဆန်ဆန် ပြနိုင်ဖို့ပဲ လိုပါတယ်။ ဒီလို မတူညီတဲ့ လိုအပ်ချက်နှစ်ခုကို Model တစ်ခုတည်းနဲ့ ဖြေရှင်းရင် အဆင်မပြေတတ်ပါဘူး။

CQRS (Command Query Responsibility Segregation) က ဒီပြဿနာကို ဖြေရှင်းဖို့ ရေးတာ (Command) နဲ့ ဖတ်တာ (Query) ကို သီးခြားစီ ခွဲထုတ်လိုက်တဲ့ Pattern ဖြစ်ပါတယ်။

1. Commands (ရေးခြင်း): System ရဲ့ Data ကို ပြောင်းလဲဖို့ သုံးပါတယ်။ ဥပမာ - CreateOrder, UpdateProfile စတာတွေပါ။ ဒီဘက်ခြမ်းမှာ Data မှန်ကန်မှုရှိဖို့ စည်းမျဉ်းစည်းကမ်း (Validation) တွေကို သေချာစစ်ဆေးပါတယ်။
2. Queries (ဖတ်ခြင်း): System ကနေ Data ပြန်ဆွဲထုတ်ဖို့ သုံးပါတယ်။ ဥပမာ - GetOrderHistory။ ဒီဘက်ခြမ်းမှာတော့ ရှုပ်ထွေးတဲ့ Rule တွေ မရှိတော့ဘဲ၊ Data ကို မြန်မြန်ဆန်ဆန် ဖတ်လို့ရအောင် အသင့်ပြင်ဆင် (Optimize) ထားတဲ့ Database မျိုးကို သုံးလေ့ရှိပါတယ်။

ဥပမာ - စားသောက်ဆိုင် မီးဖိုချောင် စားဖိုမှူး (Command) က ဟင်းချက်ဖို့ ပါဝင်ပစ္စည်းတွေကို စနစ်တကျ ချိန်တွယ်ချက်ပြုတ်ရတယ်။ ဒါက ရှုပ်ထွေးပြီး အချိန်ယူရတယ်။ ဒါပေမဲ့ စားပွဲထိုး (Query) ကတော့ ကျက်ပြီးသား ဟင်းလျာကို Customer ဆီ မြန်မြန်ဆန်ဆန် သွားချပေးရုံပါပဲ။ အလုပ်လုပ်တဲ့ ပုံစံနှစ်ခုကို သီးခြားစီ ခွဲထားတာပါ။

Event Sourcing: ဖြစ်ရပ်မှန်သမျှကို မှတ်တမ်းတင်ခြင်း

ပုံမှန်အားဖြင့် Database တွေက နောက်ဆုံးအခြေအနေ (Current State) ကိုပဲ သိမ်းထားပါတယ်။ သင့်ဘဏ်အကောင့်မှာ ငွေ $100 ရှိရင်၊ $100 လို့ပဲ သိမ်းထားပါတယ်။ အရင်က ဘာတွေဖြစ်ခဲ့လဲ ဆိုတာကို အသေးစိတ် မသိမ်းပါဘူး။

Event Sourcing ကတော့ နောက်ဆုံးအခြေအနေကို တိုက်ရိုက်မသိမ်းဘဲ၊ ပြောင်းလဲမှု ဖြစ်ရပ် (Event) တွေကို အစဉ်လိုက် မှတ်တမ်းတင်တဲ့ စနစ်ပါ။

ဥပမာ - ဘဏ်အကောင့် Event Sourcing ကို သုံးရင် Data တွေကို အောက်ကလို သိမ်းပါမယ်:

1. AccountCreated (အကောင့်စဖွင့်သည်)
2. Deposited: $500 (ငွေ $500 သွင်းသည်)
3. Withdrew: $200 (ငွေ $200 ထုတ်သည်)
4. Withdrew: $200 (ငွေ $200 ထုတ်သည်)

လက်ကျန်ငွေ $100 ဆိုတာကို တန်းမသိမ်းဘဲ၊ ဒီ Event တွေကို အစကနေ ပြန်ပေါင်းကြည့် (Replay လုပ်) မှသာ လက်ကျန်ငွေ ဘယ်လောက်ရှိလဲဆိုတာကို သိနိုင်ပါတယ်။

ဘာလို့ သုံးတာလဲ?

• Audit Log အပြည့်အစုံ ရခြင်း: ဘာတွေဖြစ်ခဲ့လဲ ဆိုတဲ့ သမိုင်းကြောင်း (History) အကုန်လုံးရှိတဲ့အတွက် အမှားရှာရ (Debug) လွယ်ကူပါတယ်။
• Data ကို ပုံစံမျိုးစုံ ပြန်သုံးနိုင်ခြင်း: ဒီ Event တွေကို အခြေခံပြီး တခြား လိုအပ်တဲ့ Data ပုံစံမျိုးစုံ (Read Models) ကို အလွယ်တကူ တည်ဆောက်နိုင်ပါတယ်။

CQRS နဲ့ Event Sourcing ပေါင်းစပ်အသုံးပြုခြင်း

ဒီ Pattern နှစ်ခုက အတွဲညီပါတယ်။

• Data ကို Write လုပ်တဲ့ Command Side မှာ Event Sourcing ကို သုံးပြီး ဖြစ်ပျက်သမျှ Event တွေကို မှတ်ထားလိုက်ပါတယ်။
• Data ကို Read လုပ်တဲ့ Query Side က အဲ့ဒီ Event တွေကို နားထောင်ပြီး၊ User တွေ မြန်မြန်ဆန်ဆန် ဖတ်လို့ရမယ့် View (Read Model) တွေကို နောက်ကွယ်ကနေ တည်ဆောက်ပေးထားပါတယ်။