Advanced Patterns: CQRS & Event Sourcing

ရည်ရွယ်ချက်

ရှုပ်ထွေးပြီး Event-driven Systems တွေမှာ မကြာခဏအသုံးပြုလေ့ရှိတဲ့ အဆင့်မြင့် pattern နှစ်ခုကို အခြေခံနားလည်နိုင်ရန်။

CQRS: “အလုပ်လုပ်တဲ့အပိုင်း” နဲ့ “Data ဖတ်တဲ့အပိုင်း” ကို ခွဲထုတ်ခြင်း

• သူဖြေရှင်းပေးတဲ့ ပြဿနာ - တစ်ခါတလေမှာ၊ သင်က data ကို create or update လုပ်ရတဲ့ ပုံစံက business rule တွေ၊ validation တွေအများကြီးနဲ့ အလွန်ရှုပ်ထွေးနေတတ်ပါတယ်။ ဒါပေမဲ့ အဲဒီ data ကို ပြန်ဖတ်ရတဲ့ပုံစံကတော့ ရိုးရှင်းပြီး အလွန်မြန်ဖို့လိုအပ်ပါတယ်။ နှစ်ခုလုံးအတွက် data model တစ်ခုတည်းကို သုံးတာက ထိရောက်မှုမရှိနိုင်ပါဘူး။

• CQRS (Command Query Responsibility Segregation) - ဒီ pattern က application model ကို သီးခြားအပိုင်းနှစ်ခုအဖြစ် ခွဲထုတ်ခြင်းဖြင့် ပြဿနာကို ဖြေရှင်းပေးပါတယ်-

  1. Commands - ဒါတွေက system ရဲ့ state ကို ပြောင်းလဲဖို့ Wrtie လုပ်တဲ့ command တွေပါ (ဥပမာ - PlaceOrderCommand, UpdateUserAddressCommand)။ ဒီလို command တွေကို ကိုင်တွယ်ဖို့နဲ့ business rule တွေကို ထိန်းချုပ်ဖို့အတွက် “Write Side” ကို optimize လုပ်ထားတဲ့ Data Model ကိုသုံးပါတယ်။

  2. Queries - ဒါတွေက system ကနေ data ဖတ်ဖို့ တောင်းဆိုချက်တွေပါ (ဥပမာ - GetOrderHistoryQuery)။ “Read side” (ဖတ်တဲ့အပိုင်း) အတွက်ကျ ကြိုတင် format ချထားပြီး မြန်မြန်ဆန်ဆန်၊ လွယ်လွယ်ကူကူ query လုပ်လို့ရအောင် optimize လုပ်ထားတဲ့ data model ကို သုံးပါတယ်။

• ဥပမာနှိုင်းယှဉ်ချက် - စာကြည့်တိုက် - Command side က စာကြည့်တိုက်မှူးတစ်ယောက် စာအုပ်အသစ်တစ်အုပ်ထည့်တဲ့ ရှုပ်ထွေးတဲ့ လုပ်ငန်းစဉ်နဲ့တူပါတယ် - ISBN ကိုစစ်ဆေး၊ အမျိုးအစားခွဲ၊ တံဆိပ်ကပ်၊ ပြီးတော့ မှန်ကန်တဲ့စင်ကိုရှာ။ ဒါက ဂရုတစိုက်နဲ့ ပုံစံကျတဲ့ လုပ်ငန်းစဉ်တစ်ခုပါ။ Query side ကတော့ သင်စာအုပ်တစ်အုပ်ရဲ့ တည်နေရာကို ချက်ချင်းရှာတွေ့နိုင်အောင် category ခွဲထားတာမျိုးပါ။ ဒီ system နှစ်ခုက သီးခြားစီဖြစ်ပြီး အလုပ်တွေအတွက် optimize လုပ်ထားကြပါတယ်။

Write commands တွေကို write လုပ်တဲ့ လုပ်ငန်းစဉ် တွေမြန်အောင် optimize လုပ်ထားပြီး Read လုပ်တာတွေ အတွက်လဲ သက်သက်စီ optimize လုပ်ထားတာမျိုးပါ။

Event Sourcing: ဘယ်တော့မှ မပျောက်ပျက်စေခြင်း

• ဘာလဲ - Application အများစုက data ရဲ့ လက်ရှိအခြေအနေ (current state) ကိုပဲ သိမ်းဆည်းလေ့ရှိပါတယ်။ ဥပမာ - သင့်ဘဏ်အကောင့်ထဲမှာ လက်ကျန်ငွေက $50 ဖြစ်ပါတယ်။ Event Sourcing ကတော့ ချဉ်းကပ်ပုံတစ်မျိုးပြောင်းလိုက်ပါတယ် - နောက်ဆုံးအခြေအနေကို သိမ်းမယ့်အစား၊ ဖြစ်ပျက်ခဲ့တဲ့ event (ဖြစ်ရပ်) တွေရဲ့ History အပြည့်အစုံ ကို သိမ်းဆည်းပါတယ်။

• ဥပမာ - “Balance: $50” ဆိုတာအစား၊ event-sourced system တစ်ခုက ဒီလိုသိမ်းဆည်းပါတယ်-

  1. AccountCreated (အကောင့်ဖွင့်ခဲ့သည်)

  2. Deposited: $100 (ငွေ $100 သွင်းခဲ့သည်)

  3. Withdrew: $20 (ငွေ $20 ထုတ်ခဲ့သည်)

  4. Withdrew: $30 (ငွေ $30 ထုတ်ခဲ့သည်)

• လက်ရှိလက်ကျန်ငွေ ($50) ကို event အားလုံးကို အစဉ်လိုက် ပြန်လည်တွက်ချက်ခြင်းဖြင့် ရရှိပါတယ်။

• အဓိကအကျိုးကျေးဇူးများ - ဖြစ်ပျက်ခဲ့သမျှအရာအားလုံးအတွက် ပြည့်စုံတဲ့ audit log (စစ်ဆေးမှုမှတ်တမ်း) တစ်ခု သင့်မှာရှိနေပါမယ်။ တိကျတဲ့ History ကို ကြည့်ပြီး ပြဿနာတွေကို debug လုပ်နိုင်သလို၊ event တွေကို ပုံစံအမျိုးမျိုးနဲ့ ပြန်လည်တွက်ချက်ပြီး data တွေ ကို နေရာအမျိုးမျိုးအတွက် အသုံးပြုနိုင်ပါတယ်။

CQRS နှင့် Event Sourcing ဘယ်လို အတူတကွ အလုပ်လုပ်သလဲ

ဒီ pattern နှစ်ခုက တစ်ခုနဲ့တစ်ခု အလွန်လိုက်ဖက်ညီပါတယ်-

• CQRS system တစ်ခုရဲ့ Command side (ရေးတဲ့အပိုင်း) က Event Sourcing ကို သုံးနိုင်ပါတယ်။ Command တစ်ခုကို process လုပ်လိုက်တဲ့အခါ၊ သူက database record ကို update မလုပ်ဘဲ၊ event အသစ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုပြီး ဖန်တီးပြီး သိမ်းဆည်းလိုက်ရုံပါပဲ။

• ပြီးတော့ Query side (ဖတ်တဲ့အပိုင်း) က ဒီ event stream ကို နားထောင်ပြီး၊ သူ့ရဲ့ ရိုးရှင်းပြီး optimize လုပ်ထားတဲ့ read model တွေကို တည်ဆောက်၊ ထိန်းသိမ်းပါတယ်။

အနှစ်ချုပ်

• Asynchronous communication က service များကို decouple (တိုက်ရိုက်မချိတ်ဆက််) ဖြစ်ပြီး system များကို ပြဿနာများမှ ဒဏ်ခံနိုင်ရည်ရှိပြီး scale လုပ်ရလွယ်ကူ စေသည်။

• အဓိက Async pattern နှစ်ခုမှာ Message Queues (တစ်ဦးမှတစ်ဦး command process လုပ်ရန်) နှင့် Publish/Subscribe (တစ်ဦးမှအများသို့ event ဖြန့်ဝေရန်) တို့ဖြစ်သည်။

• CQRS (write နှင့် read model များခွဲခြားခြင်း) နှင့် Event Sourcing ( Event History ကို သိမ်းဆည်းခြင်း) ကဲ့သို့သော အဆင့်မြင့် pattern များကို အလွန်ရှုပ်ထွေးသော system များတည်ဆောက်ရန် အသုံးပြုနိုင်သည်။