Microfrontend, microservice, monolith, monorepo, DDD တွေဆိုတာဘာတွေလဲ?

ကျနော့ အတွေ့အကြုံအရသိထားတဲ့ software architecture တွေကိုတတ်သလောက် မှတ်သလောက်လေး introduction သဘောလောက်လေး share ပါရစေ။ (By Ronald)

Microfrontend

Microfrontend ဟာ components တွေနဲ့တူပါတယ်။ ကျနော်တို့ React, Vue တို့ရေးရင် အစိတ်အပိုင်းတစ်ခုစီကို components တွေခွဲလိုက်သလိုပဲ microfrontend ဟာလည်း အဲဒီလိုအစိတ်အပိုင်းတွေခွဲပစ်တဲ့သဘောပါပဲ​။ ဒါပေမယ့် ဒီနေရာမှာ component ခွဲထုတ်တာက repo တစ်ခုတည်းမှာပဲ ခွဲလိုက်တာမျိုးပါ၊

Microfrontend ကျတော့ repo နောက်တစ်ခုခွဲထုတ်လိုက်တာမျိုးဖြစ်နိုင်သလို sevice တစ်ခုခုကနေ run နေတာမျိုးလည်းဖြစ်နိုင်ပါတယ် အဓိကကတော့ code တွေ တစ်ခုနဲ့တစ်ခု conflict မရှိအောင် team တွေနဲ့ခွဲပြီးရေးတဲ့သဘောမျိုးဖြစ်ပါတယ်။

ဥပမာ facebook app ကိုမြင်ကို microfrontend အနေနဲ့မြင်ကြည့်မယ်ဆို like feature ကို team တစ်ခု၊ comment feature ကို team တစ်ခုမှာသပ်သပ်စီ ရေးတာမျိုးဖြစ်တယ် ပြီးတော့ facebook app တစ်ခုလုံးအဆင်ပြေပြေ run နေအောင် အဲဒီ repo တွေ service တွေကနေ ပြန်ပြီးချိတ်ဆက်ထားတဲ့သဘောဖြစ်ပါတယ်။

---

Microservice

Microservice ကလည်း Microfrontend နဲ့ဆင်ပါတယ် ဒါမယ့်သူက အဓိက backend ပိုင်းကိုတာဝန်ယူတဲ့သဘောပါ

backend logic တစ်ခုလုံးကို စုပြုံပြီးရေးတာမျိုး တစ်နေရာတည်း run ထားတာမျိုးမလုပ်ပဲ service တွေလိုမျိုးခွဲထုတ်လိုက်တဲ့သဘောဖြစ်ပါတယ်

Microservice ကို သာမာန် API တွေနဲ့ခွဲတာရှိသလို messages တွေ events တွေနဲ့ခွဲလေ့ရှိပါတယ်။​

ဥပမာ e-commerce app တစ်ခုမှာ checkout, orders, products tables တွေရှိတယ်ဆိုပါစို့ အဲဒီ checkout, orders, products တွေကို Database တစ်ခုတည်းမှာပဲ စုပြုံပြီး ထည့်ထားတာမျိုးမလုပ်ပဲ သီးသန့် service တစ်ခုစီခွဲရေးလိုက်တာမျိုးဖြစ်ပါတယ် service တစ်ခုနဲ့တစ်ခုကို events တွေအပြန်အလှန်ပစ်ပြီး ဆက်သွယ်တာမျိုးဖြစ်ပါတယ်။

အဲဒီတော့ တကယ်လို့ checkout service က down သွားတယ်ဆိုရင်တောင် orders နဲ့ products ကိုထိခိုက်တာမျိုးမရှိပဲ ဆက် run နေမှာပဲဖြစ်ပါတယ်။

---

Monolith

Monolith ကျတော့ microservice နဲ့ဆန့်ကျင်ဘက်ပေါ့ဗျာ

အရင်က traditional approach နည်းလမ်းဟောင်းလို့လည်းပြောရင်မမှားပါဘူး application logic တွေအကုန်လုံးကို တစ်နေရာတည်းမှာပဲ စုပြုံထားတဲ့သဘောဖြစ်ပါတယ်။

သူမှာ အားသာချက်တော့ repo တွေ service တွေအများကြီးခွဲစရာမလိုပဲ တစ်နေရာတည်းမှာ manage လုပ်နိုင်ပါတယ်။ developer တွေအကုန်လုံးလည်းပေါင်းပြီး ရေးကြတော့ managment ပိုင်းမှာအားသာပါတယ်။

အားနည်းချက်ကတော့ horizontal scaling လုပ်လို့မရပဲ​ vertical scaling မျိုးပဲဖြစ်သွားပါတယ်။ သဘောက application ကြီးလာလေလေ အဲဒီ repo ကကြီးလာလေလေဖြစ်ပြီး team member တွေတစ်ခုခုပြင်မယ်ဆို သေသေချာချာစီစစ်ရပါတယ် မဟုတ်ရင် production တစ်ခုလုံး down သွားတာမျိုးဖြစ်နိုင်ပါတယ်။ ပြီးတော့ local setup တွေလုပ်မယ် test လုပ်မယ်ဆိုရင် size အရမ်းကြီးတော့ memory တွေအရမ်းစားတာမျိုးဖြစ်နိုင်ပါတယ်။

Monorepo

Monorepo အခုနောက်ပိုင်း ခေါတ်စားနေတဲ့ approach တစ်ခုပဲဖြစ်ပါတယ်၊ များသောအားဖြင့် frontend library တွေ framework တွေအရမ်းသုံးကြပါတယ်။

သူက ဘယ်လိုပြဿနာမျိုးကိုဖြေရှင်းပေးတာလဲ ? frontend app တွေမှာ dependencies တွေအရမ်းများလာရင် ထိန်းရသိမ်းရ အရမ်းခက်ခဲပါတယ်

• ၂ ရက်လောက်နေရင် ကိုယ်ရေးတဲ့ code deprecate ဖြစ်သွားတယ်
• developer အသစ်တစ်ယောက်ဝင်လာရင် နောက်ထပ် library တစ်ခုထည့်လိုက်တော့ library တွေထပ်သွားတာမျိုးရှိတတ်ပါတယ်။
• နောက်ပြီးတော့ versioning က ဟို code နဲ့မကိုက် ဒီ code နဲ့မကိုက် conflict ဖြစ်တတ်ပါတယ်။

ဒီပြဿနာတွေကို monorepo ကဖြေရှင်းပေးတာမျိုးရှိပါတယ်။ ဘယ်လိုဖြေရှင်းပေးတာလဲဆိုတော့

ပုံမှန်အားဖြင့် custom ရေးထားတဲ့ library ကိုထပ်ခါထပ်ခါသုံးမယ်ဆို ကျနော် npm libary တွေကို npm ပေါ် publish လုပ်ပါတယ် monorepo လုပ်ထားရင် publish လုပ်စရာမလိုပဲ packages/ ဆိုတဲ့ folder ထဲထည့်ပြီး သုံးလို့ရတာမျိုးလုပ်ပေးပါတယ်။

လက်ရှိသုံးနေတဲ့ library က deprecate လုပ်သွားတယ်ဆိုရင်တောင် ကိုယ့် project packages folder မှာအဲဒီ library နဲ့ stable version ကိုထည့်ထားလို့ရပါတယ်။

နောက်ပြီးတော့ frontend app မှာလဲ toast library သုံးတယ် backend မှာလည်းသုံးတယ် ဆိုပါစို့ frontend ရော backend ရော 2 ခုစလုံးမှာ toast library ကို share ပြီးသုံးလို့ရပါတယ် ခုဏက packages ဆိုတဲ့ folder မှာပဲပြန်ဆွဲသုံးလို့ရအောင်လုပ်ပေးတာမျိုး လုပ်နိုင်ပါတယ်။

Domain-Driven Design (DDD)

DDD ကတော့ code ရေးတဲ့အပိုင်း project folder ဆောက်တဲ့ အပိုင်းမှာပိုအသုံးများပါတယ်။ အဓိကကတော့ maintain လုပ်ရလွယ်အောင် လူနားလည်လွယ်အောင် လုပ်တာမျိုးဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့် application တွေ framework တွေဟာ သူ့နည်းသူ့ဟန်နဲ့ code တွေ folder တွေ structure ချထားတာမျိုးရှိတယ် အဲဒါကိုကျနော်တို့က လိုက်နာရပါတယ်။

တခါတလေ performance တွေ speed တွေ clean code တွေအတွက်အဆင်ပြေပေမယ့် Business logic မှာ fail နေတာမျိုးဖြစ်တတ်ပါတယ်။ အဲဒီတော့ maintain လုပ်ရတဲ့အပိုင်းမှာ ရှုပ်ထွေးကုန်တာမျိုးဖြစ်တတ်ပါတယ်။

ဥပမာ products, orders, payments တွေကို Refactor လုပ်လိုက်တယ်ဆိုပါစို့ code ကရှင်းထွက်နေပြီး Business logic တွေငြိနေတာမျိုးကြုံဖူးမှာပါ၊ product ထဲမှာ payment အပိုင်းတွေရောက်နေသလို order ထဲမှာလည်း ရောက်နေတာမျိုးရှိနိုင်ပါတယ်။

အဲဒါကို domain တစ်ခုစီ folder တစ်ခုစီ သီးသန့်ခွဲပြီး structure သေချာချတာမျိုးဖြစ်ပါတယ်။ တခြား repo တွေ service တွေနဲ့ချိတ်ဆက်တာမျိုးဆိုတာထက် လက်ရှိ project တစ်ခုတည်း Business logic အပေါ်မှာမူတည်ပြီး structure ကိုသေချာချတာမျိုးဖြစ်ပါတယ်။