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

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

ရည်ရွယ်ချက်

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

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

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

စိတ်ထင်နဲ့မဆုံးဖြတ်ဘဲ စနစ်တကျ ဆုံးဖြတ်ခြင်း

“ငါတော့ ဒါလေးကောင်းမယ်ထင်တယ်” ဆိုပြီး ရမ်းမဆုံးဖြတ်ဘဲ၊ အောက်ပါအတိုင်း အဆင့် ၄ ဆင့်နဲ့ စဉ်းစားကြည့်ပါ:

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

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

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

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

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

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

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

လက်တွေ့လောကရဲ့ အခက်အခဲများကို ထည့်သွင်းစဉ်းစားခြင်း

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

• အချိန် နှင့် ဘတ်ဂျက်: အကောင်းဆုံးနည်းလမ်းက ရေးဖို့ တစ်နှစ်ကြာမယ်၊ ကိုယ့်မှာ အချိန် ၃ လပဲ ရှိတယ်ဆိုရင် အဲ့ဒီနည်းလမ်းကို သုံးလို့ မရပါဘူး။
• Team ရဲ့ ကျွမ်းကျင်မှု: Team ထဲကလူတွေက REST API ကိုပဲ ကျွမ်းပြီး Message Queue ကို တစ်ခါမှ မသုံးဖူးဘူးဆိုရင်၊ သင်ယူရမယ့် အချိန်ကိုပါ ထည့်တွက်ရပါမယ်။
• လုပ်ငန်းရဲ့ ရည်မှန်းချက်: တချို့အချိန်တွေမှာ ကုဒ်တွေ ဘယ်လောက်လှလှ သိပ်အရေးမကြီးဘဲ၊ Product ကို ဈေးကွက်ထဲ အမြန်ဆုံးချပြနိုင်ဖို့က ပိုအရေးကြီးတတ်ပါတယ်။