တော်တော်များများ developer တွေ ဖြစ်လေ့လုပ်လေ့ရှိတဲ့အရာကတော့ application တခုစပြီဆိုရင် architecture ကို သေချာအရင် မစဥ်းစားဘဲ codeကို ချရေးလေ့လုပ်လေ့ရှိတာပါပဲ။ appတခုရေးတော့မယ်ဆိုရင် သူ့အတွက် ဘယ် architecture သုံးမလဲ သပ်သပ်မှတ်မှတ် မစဥ်းစားခင်မှာပဲ developer နဲ့ architects တွေက များသောအားဖြင့် ပုံမှန်သုံးနေကျ traditional layered architecture pattern ( တနည်းအားဖြင့် n-tired architecture) နဲ့ ၊ ပြီးရင် modules တွေခွဲမယ် ဒီလိုနဲ့ ဖန်တီးလေ့ရှိတယ်။ တခါတရံမှာ ကံအကြောင်းမလှဘဲ roles တွေ responsibility တွေ သူတို့အချင်းချင်း relationship တွေက ရှင်းလင်းပြတ်သားနေတာမရှိဘဲ ရှုပ်ထွေးရောယှက်နေတဲ့ source-codes တွေဖြစ်နေတတ်တယ်။
အဲလို applicationတွေက ပြင်ဆင်ဖို့လည်း ခက်ခဲပြီး module တခုနဲ့တခု tightly coupledဖြစ်နေတာ့ deployment နဲ့ maintenance လုပ်ဖို့အတွက် အနည်းဆုံးကြုံတွေ့ရနိုင်တဲ့ ပြဿနာတွေတောင် အဖြေထုတ်ရကြပ်လာတယ်။ ဥပမာ၊ scale လုပ်ချင်ရင်ကော အဆင်ပြေရဲ့လား ? performance ကကော ဘယ်လိုအခြေနေရှိလဲ? ဒီနေရာလေးပြင်လိုက်ရင်ကော တခြားနေရာတွေ ထိသွားနိုင်လား? specific module တခုပဲ version upဖို့ deployချမယ်ဆိုရင်ကော တခြားနေရာတွေ အဆင်ပြေပါ့မလား ?
ဒီနေရာမှာ architecture patterns တွေက application တခုရဲ့ behavior နဲ့ characteristics တွေကို နားလည်ပြီး သုံးသပ်နိုင်ဖို့ အထောက်ကူပြုပါတယ်။ ဥပမာ၊ တချို့ architecture တွေက highly scalable အတွက် ကောင်းပြီး တချို့က agile အတွက် အဆင်ပြေစေတာမျိုး။ ဒါ့ကြောင့် architecture pattern တခုစီရဲ့ characteristics , strengths နဲ့ weakness တွေကိုသိခြင်းအားဖြင့် ကိုယ့်ရဲ့ application လိုအပ်ချက်တွေနဲ့ ကိုက်ညီမယ့်တခုကို ရွေးလို့ရနိုင်ပါတယ်။
Architectတယောက်အနေနဲ့ ကိုယ့်ရဲ့ architecture pattern တွေကို ဆုံးဖြတ်ဖို့ လိုလာတဲ့အခါ ဘယ်အချက်တွေကြည့်ပြီး ဘယ်လိုဆုံးဖြတ်မှာလဲ အများလက်ခံနေကြ standard အတိုင်းပဲ ရှေးရိုးနည်းနဲ့ ပဲ ဆုံးဖြတ်မလား fact တွေနဲ့ပဲ ဆုံးဖြတ်မလား? ဒီpatternတွေအကြောင်းတော့ အနည်းနဲ့အများ သိသင့်တယ်လို့ထင်ပါတယ်။