အပေါ်ယံခြုံငုံသုံးသပ် ဒီဇိုင်းဆွဲခြင်းနှင့် Pattern ရွေးချယ်ခြင်း

အဆင့် 3: အဓိက Pattern တစ်ခုကို ရွေးချယ်ခြင်း

လိုအပ်ချက်တွေရပြီဆိုတော့ ဘယ်လို Pattern နဲ့ ရေးမလဲ စဉ်းစားကြည့်ရအောင်။

Monolith လား? App တစ်ခုလုံးကို Codebase တစ်ခုတည်းနဲ့ ရေးရင် အခက်အခဲတွေ အများကြီးရှိပါတယ်။ ဥပမာ - “ကားသမားရဲ့ နေရာကို အမြဲပြပေးရမယ့် Feature” က “User အကောင့်ဖွင့်တဲ့ Feature” ထက် အများကြီး ပိုပြီး ဝန်ပိပါတယ်။ နောက်ပြီး User အကောင့်ဖွင့်တဲ့နေရာမှာ Error တက်သွားရင် App တစ်ခုလုံး Crash ဖြစ်ပြီး ကားခေါ်လို့ပါ မရတော့တဲ့အထိ ဖြစ်သွားနိုင်ပါတယ်။ ဒါကြောင့် Monolith နဲ့ မသင့်တော်ပါဘူး။
Microservices လား? ဒါကတော့ အကိုက်ညီဆုံးပါပဲ။ ကျွန်တော်တို့က Feature တွေကို အပိုင်းလိုက် Service လေးတွေ (ဥပမာ - Location, Trip, Driver) ခွဲထုတ်လိုက်ပါမယ်။ Service တစ်ခုကို လူသုံးများလာရင် အဲ့ဒီတစ်ခုတည်းကိုပဲ ဆာဗာ (Server) ထပ်ဝယ်ပြီး Scale လုပ်လို့ရပါတယ်။ ပြီးတော့ Driver Service ထဲမှာ Error တက်နေရင်တောင် Location Service က ကောင်းနေတဲ့အတွက် မြေပုံက ဆက်အလုပ်လုပ်နေပါလိမ့်မယ်။

ဆုံးဖြတ်ချက်: Microservices Architecture ကို ရွေးချယ်ပါမယ်။

အဆင့် 4: Service လေးတွေ ခွဲထုတ်ခြင်း (Service Boundaries)

App ကြီးတစ်ခုလုံးကို အလုပ်လုပ်တဲ့ သဘောသဘာဝအလိုက် အောက်ပါအတိုင်း Service ၅ ခု ခွဲထုတ်လိုက်ပါမယ်။

Rider Service: ကားငှားမယ့်သူတွေရဲ့ အချက်အလက် (Profile၊ Rating၊ ကတ်နံပါတ်) တွေကို ထိန်းသိမ်းပေးပါတယ်။
Driver Service: ကားသမားတွေရဲ့ အချက်အလက် (Profile၊ ကားလိုင်စင်၊ အား/မအား အခြေအနေ) တွေကို ထိန်းသိမ်းပေးပါတယ်။
Trip Service: App ရဲ့ အဓိက ဦးနှောက်ပါပဲ။ ကားခေါ်တာကို လက်ခံမလား၊ ဘယ်လောက်ကျမလဲ၊ ကားသမားနဲ့ ဘယ်လိုချိတ်ပေးမလဲ ဆိုတဲ့ ခရီးစဉ်တစ်ခုလုံးရဲ့ လုပ်ငန်းစဉ်ကို စီမံပေးပါတယ်။
Location Service: ကားသမား ထောင်ပေါင်းများစွာဆီကနေ စက္ကန့်နဲ့အမျှ ပို့နေတဲ့ GPS တည်နေရာတွေကို အမြန်ဆုံး ဖမ်းယူသိမ်းဆည်းပေးတဲ့ သီးသန့် Service ပါ။
Notification Service: User တွေဆီကို SMS (သို့) Push Notification လှမ်းပို့ပေးမယ့် Service ပါ။ တခြား Service တွေက သူ့ကို “ဒီစာလေး ပို့ပေးပါ” လို့ လှမ်းခိုင်းရုံပါပဲ။

အဆင့် 5: ပုံကြမ်းများဆွဲခြင်း (C4 Model ကို သုံးပြီး)