ဆုံးဖြတ်ချက်များ၊ ပုံကြမ်းများ နှင့် မှတ်တမ်းများ

မတူညီတဲ့ Architectural Pattern တွေအကြောင်း သိတာက တစ်ပိုင်း အဲဒါတွေကို လက်တွေ့မှာ အသုံးချတာက နောက်တစ်ပိုင်းပါ။ Architecture ဆိုတာ နည်းပညာ Pattern တွေအကြောင်းသက်သက်မဟုတ်ပါဘူး။ ဒါက ခက်ခဲတဲ့ဆုံးဖြတ်ချက်တွေချမှတ်ခြင်း၊ ရှုပ်ထွေးတဲ့အကြံဉာဏ်တွေကို ရှင်းလင်းစွာ ဆက်သွယ်ပြောဆိုခြင်း၊ နှင့် အဲဒီဆုံးဖြတ်ချက်တွေကို အနာဂတ်အတွက် မှတ်တမ်းတင်ခြင်းတို့ ပါဝင်တဲ့ “လက်မှုပညာ” တစ်ခုဖြစ်ပါတယ်။ ဒီအခန်းမှာတော့ Software Architect တိုင်းအတွက် နေ့စဉ်လိုအပ်တဲ့ လက်တွေ့ကျွမ်းကျင်မှုတွေကို အဓိကထား လေ့လာပါမယ်။

အပေးအယူမျှတမှု အနုပညာ နှင့် ဆုံးဖြတ်ချက်ချမှတ်ခြင်း

ရည်ရွယ်ချက်

• Architectural ဆုံးဖြတ်ချက်တွေချမှတ်ဖို့အတွက် စနစ်တကျချဉ်းကပ်ပုံကို လေ့လာရန်။
• နည်းပညာဆိုင်ရာရည်မှန်းချက်တွေရရှိဖို့အတွက် လက်တွေ့လုပ်တဲ့အခါ ဖြစ်ပေါ်လာတဲ့ ကန့်သတ်ချက်တွေနဲ့ ချိန်ညှိခြင်းများကို နားလည်စေရန် ဖြစ်ပါတယ်။

Architecture ဆိုတာ ရွေးချယ်မှုတွေရဲ့ ကစားပွဲတစ်ခုပါ

ကျွန်တော်တို့ ရှေ့ဆုံးအခန်းမှာ လေ့လာခဲ့သလိုပဲ၊ တစ်ခုတည်းသော “အကောင်းဆုံး” Architecture ဆိုတာမရှိပါဘူး။ သင်ချမှတ်လိုက်တဲ့ ရွေးချယ်မှုတိုင်းမှာ အားသာချက်နဲ့ အားနည်းချက်တွေ ရှိပါတယ်။ Architect တစ်ယောက်ရဲ့ ကျွမ်းကျင်မှုဆိုတာက ဒီအပေးအယူမျှတမှု (Trade-offs) တွေကို နားလည်ပြီး ဖြစ်နိုင်သမျှ အကောင်းဆုံးရွေးချယ်မှုကို ပြုလုပ်နိုင်ခြင်းဖြစ်ပါတယ်။

စိတ်ထင်နဲ့ဆုံးဖြတ်တာထက် ပိုကောင်းတဲ့နည်း - ရိုးရှင်းတဲ့ Decision Framework

“စိတ်ထင်” နဲ့ပဲ ဆုံးဖြတ်မယ့်အစား၊ သင့်ဆုံးဖြတ်ချက်တွေကို ချမှတ်ဖို့နဲ့ အကြောင်းပြချက်ခိုင်မာစေဖို့အတွက် ရိုးရှင်းပြီး စနစ်တကျရှိတဲ့ Process တစ်ခုကို သုံးနိုင်ပါတယ်:

• အဆင့် ၁: ကိုယ့်မှာ ဘာရွေးချယ်စရာတွေ ရှိလဲ သတ်မှတ်ပါ။ သင်စဉ်းစားနေတဲ့ လက်တွေ့ကျတဲ့ ရွေးချယ်စရာ ၂-၃ ခုကို ရှင်းရှင်းလင်းလင်း သတ်မှတ်လိုက်ပါ။

  • ဥပမာ: “Order Notification တွေကို ကိုင်တွယ်ဖို့အတွက် ကျွန်တော်တို့မှာ ရွေးချယ်စရာတွေကတော့ - (A) Message Queue သုံးမလား၊ ဒါမှမဟုတ် (B) Order Service ကနေ Notification Service ကို တိုက်ရိုက် API Call သုံးမလား။”

• အဆင့် ၂: ဘာက အရေးအကြီးဆုံးလဲဆိုတာ သတ်မှတ်ပါ။ ဒီဆုံးဖြတ်ချက်အတွက် ဘာက အရေးအကြီးဆုံးလဲ။ သက်ဆိုင်ရာ Quality Attributes တွေကို စာရင်းပြုစုပါ။

  • ဥပမာ: “အဓိကအချက်တွေကတော့ - Resilience (Notification Service သာ ပျက်နေရင် ဘယ်လိုလုပ်မလဲ။)၊ Performance (Order တွေကို ဘယ်လောက်မြန်မြန် Process လုပ်နိုင်မလဲ။)၊ နဲ့ Development Speed (ဘယ်လောက်မြန်မြန် တည်ဆောက်နိုင်မလဲ။) တို့ ဖြစ်ပါတယ်။”

• အဆင့် ၃: ရွေးချယ်စရာတွေကို အမှတ်ပေးကြည့်ပါ (The Decision Matrix)။ သင့်ရွေးချယ်စရာတွေကို သင့်စံနှုန်းတွေနဲ့ နှိုင်းယှဉ်ဖို့ ရိုးရှင်းတဲ့ဇယားတစ်ခု ဖန်တီးပါ။ ++ (အလွန်ကောင်း)၊ + (ကောင်း)၊ - (မကောင်း)၊ -- (အလွန်မကောင်း) လိုမျိုး ရိုးရှင်းတဲ့ အမှတ်ပေးစနစ်ကို သုံးနိုင်ပါတယ်။

ရွေးချယ်စရာ	Resilience	Performance	Development Speed
A: Message Queue	++	+	-
B: တိုက်ရိုက် API Call	--	++	++

• အဆင့် ၄: ဆုံးဖြတ်ချက်ချပြီး အကြောင်းပြချက်ပေးပါ။ အပေါ်ကဇယားက အပေးအယူတွေကို ရှင်းရှင်းလင်းလင်းမြင်စေပါတယ်။ ဥပမာမှာ၊ API Call က တည်ဆောက်ရတာ ပိုမြန်ပေမယ့်၊ Message Queue ကတော့ Resilience မှာ အများကြီးသာပါတယ်။ သင့် Project ရဲ့ ဦးစားပေးအချက်တွေပေါ်မူတည်ပြီး၊ အခုဆိုရင် အချက်အလက်အစုံအလင်နဲ့ ဆုံးဖြတ်ချက်တစ်ခုကို ချမှတ်နိုင်ပါပြီ။

  • ဥပမာ ဆုံးဖြတ်ချက်: “တည်ဆောက်ရတာ ပိုကြာနိုင်ပေမယ့်၊ Order တွေကို Process လုပ်ရာမှာ Resilience က ကျွန်တော်တို့အတွက် အဓိကဦးစားပေးဖြစ်လို့ Message Queue ကိုပဲ ရွေးချယ်ပါတယ်။“

လက်တွေ့ကို ထည့်သွင်းစဉ်းစားခြင်း - လုပ်ငန်းဆိုင်ရာ ကန့်သတ်ချက်များ

နည်းပညာအရ အကောင်းဆုံးဖြေရှင်းချက်တွေက လုပ်ငန်းရဲ့လိုအပ်ချက်တွေနဲ့ မကိုက်ညီရင် အသုံးမဝင်ပါဘူး။ ဒီလက်တွေ့မှာ ကန့်သတ်ချက်တွေကို အမြဲထည့်သွင်းစဉ်းစားရပါမယ်-

• အချိန် နဲ့ ဘတ်ဂျက် - ပြီးပြည့်စုံတဲ့ ဖြေရှင်းချက်က တည်ဆောက်ဖို့ တစ်နှစ်လောက်ကြာနိုင်ပေမယ့်၊ သင့်မှာ အချိန်သုံးလပဲ ရှိနိုင်ပါတယ်။

• Team ရဲ့ ကျွမ်းကျင်မှု - သင့် Team က REST API တွေကို ကျွမ်းကျင်နိုင်ပေမယ့်၊ Message Queue ကို ဘယ်တုန်းကမှ မသုံးဖူးတာမျိုး ဖြစ်နိုင်ပါတယ်။ လေ့လာသင်ယူရမယ့်အချိန်က ကုန်ကျစရိတ်တစ်ခုပါ။

• လုပ်ငန်းရဲ့ ရည်မှန်းချက် - အရေးအကြီးဆုံးရည်မှန်းချက်က ကျန်တာတွေ သိပ်မကောင်းရင်တောင် ဈေးကွက်ထဲကို အမြန်ဆုံးရောက်ရှိဖို့ ဖြစ်နိုင်ပါတယ်။