Architecture ၏ ရည်မှန်းချက်များ
Feature များအပြင် System မည်မျှကောင်းမွန်သနည်း
Section titled “Feature များအပြင် System မည်မျှကောင်းမွန်သနည်း”Architecture ဆိုတာ System တစ်ခုက ဘာတွေလုပ်ပေးနိုင်သလဲ (Features) ဆိုတာထက်၊ အဲ့ဒီအလုပ်တွေကို ဘယ်လောက်ကောင်းကောင်း လုပ်ဆောင်နိုင်သလဲ ဆိုတာကို အဓိကထားပါတယ်။ ဒီ “ဘယ်လောက်ကောင်းကောင်း” ဆိုတဲ့ အရည်အသွေးတွေကို Quality Attributes ဒါမှမဟုတ် “-ilities” လို့ခေါ်ပါတယ်။ ဒါတွေက ကိုယ့်ရဲ့ Architectural Blueprint ကို ပုံဖော်ပေးမယ့် အဓိကရည်မှန်းချက်တွေ ပါပဲ။
အရေးအကြီးဆုံး Quality Attributes တွေထဲက တချို့ကတော့:
-
Performance (တုံ့ပြန်မှုအမြန်နှုန်း) ⏱️
- ဆိုလိုရင်း: System က Request တစ်ခုကို ဘယ်လောက်မြန်မြန်တုံ့ပြန်သလဲ။ ဒါကို Latency (ကြာချိန်) နဲ့ Throughput (အချိန်တစ်ခုအတွင်း ပြီးမြောက်တဲ့အလုပ်) နဲ့ တိုင်းတာပါတယ်။
- Architect အနေဖြင့် စဉ်းစားရန်: “User တစ်သန်း တစ်ပြိုင်နက်တည်း သုံးနေရင်တောင်၊ Search Result တွေက ဘယ်လောက်မြန်မြန်ပေါ်လာသင့်လဲ?”
-
Scalability (တိုးချဲ့နိုင်စွမ်း) 📈
- ဆိုလိုရင်း: System က တိုးလာတဲ့ User တွေနဲ့ Data တွေကို စွမ်းဆောင်ရည်မကျဘဲ ထိထိရောက်ရောက် ကိုင်တွယ်နိုင်ရဲ့လား။
- Architect အနေဖြင့် စဉ်းစားရန်: “ကျွန်တော်တို့ရဲ့ User အရေအတွက်က တစ်ညတည်းနဲ့ နှစ်ဆတိုးလာခဲ့ရင်၊ System က မကျသွားဘဲ၊ မနှေးသွားဘဲ ကိုင်တွယ်နိုင်ပါ့မလား?”
-
Availability / Reliability (အမြဲသုံးနိုင်မှု / ယုံကြည်စိတ်ချရမှု) ✅
- ဆိုလိုရင်း: System က ပျက်မကျဘဲ ပုံမှန်အလုပ်လုပ်နေတဲ့ အချိန်ရာခိုင်နှုန်း။ ဒါကို “Nines” (ဥပမာ - 99.9% Uptime) နဲ့ တိုင်းတာလေ့ရှိပါတယ်။
- Architect အနေဖြင့် စဉ်းစားရန်: “Server တစ်လုံးပျက်သွားရင်၊ Website တစ်ခုလုံး ရပ်သွားမှာလား၊ ဒါမှမဟုတ် ဆက်အလုပ်လုပ်နေနိုင်မလား?”
-
Maintainability (ပြင်ဆင်ထိန်းသိမ်းရလွယ်ကူမှု) 🔧
- ဆိုလိုရင်း: Developer တွေအတွက် Bug တွေကို ရှာဖွေပြင်ဆင်ဖို့၊ Update တွေလုပ်ဖို့၊ Feature အသစ်တွေထည့်ဖို့ ဘယ်လောက်လွယ်ကူသလဲ။
- Architect အနေဖြင့် စဉ်းစားရန်: “Developer အသစ်တစ်ယောက်က ဒီ System ရဲ့ အစိတ်အပိုင်းတစ်ခုကို နားလည်ပြီး ပြောင်းလဲမှုတစ်ခုလုပ်ဖို့ ဘယ်လောက်ကြာမလဲ?”
-
Security (လုံခြုံရေး) 🛡️
- ဆိုလိုရင်း: System ရဲ့ Data နဲ့ လုပ်ဆောင်ချက်တွေကို ခြိမ်းခြောက်မှုတွေနဲ့ ခွင့်ပြုချက်မရှိဘဲ ဝင်ရောက်ခြင်းကနေ ကာကွယ်နိုင်စွမ်း။
- Architect အနေဖြင့် စဉ်းစားရန်: “ကျွန်တော်တို့က User Password တွေကို ဘယ်လိုကာကွယ်ထားသလဲ၊ SQL Injection လိုမျိုး အဖြစ်များတဲ့ တိုက်ခိုက်မှုတွေကို ဘယ်လိုကာကွယ်မလဲ?”
-
Testability (စမ်းသပ်ရလွယ်ကူမှု) 🧪
- ဆိုလိုရင်း: System က ကောင်းကောင်းအလုပ်လုပ်ရဲ့လားဆိုတာကို စမ်းသပ်စစ်ဆေးဖို့ ဘယ်လောက်လွယ်ကူသလဲ။
- Architect အနေဖြင့် စဉ်းစားရန်: “ကျွန်တော်တို့ System ရဲ့ အစိတ်အပိုင်းတစ်ခုချင်းစီကို သီးခြားခွဲပြီး စမ်းသပ်နိုင်လား၊ ဒါမှမဟုတ် တစ်ခုလုံးကို တစ်ခါတည်း စမ်းသပ်ရမှာလား?”
အဓိကနိယာမ - Architecture သည် Trade-offs များဖြစ်သည်
Section titled “အဓိကနိယာမ - Architecture သည် Trade-offs များဖြစ်သည်”တစ်ပြိုင်နက်တည်းမှာ အမြန်ဆုံး၊ အတိုးချဲ့နိုင်ဆုံး၊ အလုံခြုံဆုံး၊ တည်ဆောက်ထိန်းသိမ်းဖို့ အကုန်အကျအသက်သာဆုံးဖြစ်တဲ့ System တစ်ခုကို ဘယ်တော့မှ တည်ဆောက်လို့မရပါဘူး။ Architectural ဆုံးဖြတ်ချက်တိုင်းမှာ အပေးအယူ (Trade-off) တစ်ခုရှိပါတယ်။ Quality Attribute တစ်ခုကို ပိုကောင်းအောင်လုပ်လိုက်ရင်၊ တခြားတစ်ခုကို အလျှော့ပေးရလေ့ရှိပါတယ်။
-
ဥပမာ 1: Performance vs. Security System တစ်ခုကို ပိုလုံခြုံအောင်လုပ်ဖို့၊ Data Encryption အလွှာတွေ၊ ရှုပ်ထွေးတဲ့ Validation Check တွေ ထပ်ထည့်ရနိုင်ပါတယ်။
ဒီအဆင့်တွေက Processing အချိန်ပိုယူတဲ့အတွက်၊ System ရဲ့ Performance ကို အနည်းငယ်နှေးသွားစေနိုင်ပါတယ်။
-
ဥပမာ 2: Maintainability vs. Performance System တစ်ခုကို ထိန်းသိမ်းရလွယ်ကူအောင်လုပ်ဖို့၊ Code တွေကို သေးငယ်ပြီး တာဝန်ကိုယ်စီသတ်မှတ်ထားတဲ့ Layer တွေ၊ Service တွေအဖြစ် ခွဲထုတ်နိုင်ပါတယ်။
ဒီ Service တွေက Network ကနေတစ်ဆင့် ဆက်သွယ်တဲ့အခါ Latency (ကြာချိန်) ဖြစ်ပေါ်စေပြီး၊ System ကို တစ်သားတည်းပေါင်းစပ်ထားတဲ့ Monolith တစ်ခုထက် Performance ပိုနည်းသွားစေနိုင်ပါတယ်။
