user
Data State များ


assistant
Data State လို့ ပြောလိုက်ရင် အရင်ဆုံး မျက်စိထဲမှာ မြင်မိတာ State Machine တွေ သင်ခဲ့တုန်းက Turnstile ဥပမာပါပဲ။ ငွေအကြွေစိထည့်ပြီး တွန်းဝင်လို့ရတဲ့ ဂိတ်တွေပေါ့။ အဲဒီအကြောင်း သိချင်ရင် Infinite State Machine ဆိုပြီး ရှာလိုက်ပါ။ Wiki မှာလဲ ဖတ်လို့ရပါတယ်။
Current State က Locked ဖြစ်နေမယ်။ အဲဒါကို Coin ထည့်လိုက်မယ်ဆိုရင် နောက် State က Unlocked ဖြစ်သွားတဲ့ State ပါ။ Unlocked ဖြစ်သွားတဲ့အတွက် အသုံးပြုသူအနေနဲ့ တွန်းဝင်သွားလို့ရပါမယ်။ Unlocked State မှာ Push လုပ်ပြီး တွန်းဝင်သွားတဲ့အတွက် နောက် State က Locked ဖြစ်တဲ့အတွက် Turnstile က locked ဖြစ်သွားပါမယ်။
ဒါကတော့ Infinite State Machine ကို စသင်ပြီဆိုတာနဲ့ နမူနာပေးတဲ့ ပုံစံပါ။ အမှန်တကယ် လက်တွေ့မှာရော ဘယ်လိုတွေ သုံးကြမလဲ။ ဒါကတော့ အသုံးပြုချင်တဲ့ နည်းပညာရဲ့အပေါ်မူတည်ပါလိမ့်မယ်။ ကျွန်တော်ကတော့ Data Intensive ဖြစ်တဲ့ Service တွေအတွက် ရည်ရွယ်ပြီး ဆက်ပြောပါမယ်။

Data Intensive Application များနှင့် State များ
ကျွန်တော်တို့မှာ Online Shop တစ်ခု ရှိတယ်ဆိုကြပါစို့။ အဲဒီမှာ အရင်ဆုံး လုပ်ရမှာ Data Entry ပါ။ အဲဒီအတွက် အသေးစိတ်တော့ မပြောတော့ပေမယ့် ရှင်းပြလို့ မြင်သာအောင်တော့ ပုံစံချထားပါတယ်။
Staff က Stock Entry လုပ်တယ်ဆိုပါစို့။ Business Requirement အရ Data Entry ကို တစ်ကြိမ်တည်းထည့် တစ်ခါတည်း Publish လုပ်တဲ့ ပုံစံသွားလို့မရဘူးဆိုပါစို့။ အဲဒီအခါ ကျွန်တော်တို့အနေနဲ့ Draft လုပ်လို့ရတဲ့ Feature ကို ထည့်ပေးရပါမယ်။ အဲဒီအပြင် အဲဒီ​ Draft မှာ နောက်ပြန် Replay လုပ်ချင်တဲ့ Feature လဲ ထည့်ပေးရမယ် ဆိုပါစို့။ အဲဒီလို အခြေအနေမျိုးမှာ ကျွန်တော်တို့ Data State တွေကို လေ့လာလို့ရနိုင်ပါတယ်။
အခုချထားတာက နမူနာပုံစံပါ။ လက်တွေ့မှာတော့ ဒီထက် စဉ်းစားစရာတွေ အများကြီး ရှိပါတယ်။ Staff က Stock Entry လုပ်တယ်။ Action အနေနဲ့ Draft နှစ်ခါ၊ Save တစ်ခါနဲ့ Publish တစ်ခါ လုပ်ပါတယ်။ ကျွန်တော်တို့ Draft တွေကိုတော့ Main Stock Table ထဲ မထည့်သေးပါဘူး။ ဘာကြောင့်လဲဆိုတော့ Stock Table ထဲမှာ ရှုပ်မှာစိုးလို့ပါ။ အဲဒီအတွက် History Table တစ်််ခုဖန်တီးပြီး Row အလိုက် မှတ်ထားပါတယ်။
အဲဒီအပြင် Replay ပါ လုပ်ချင်အတွက် Snapshot တွေလဲ သိမ်းထားပါတယ်။ ထုံးစံအတိုင်း created_at, updated_at, deleted_at ဆိုတာတွေတော့ ရှိမှာပေါ့။ State တစ်ခုချိန်းသွားတဲ့ Action တွေက Trigger လုပ်လို့လိုပါတယ်။ အဲဒီမှာ ပါတဲ့ State တွေကို ခွဲခြားကြည့်မယ်ဆိုရင်
- Linear States
- Non-linear States
ဆိုပြီး တွေ့ရပါလိမ့်မယ်။

Linear States
Linear States တွေရဲ့ အဓိက ကျတဲ့အချက်ကတော့ ရှေ့ကိုပဲ သွားနေတာပါ။ နောက်ပြန်လှည့်လို့မရပါဘူး။ (SE အရ အခေါ်အဝေါ်တူချင်မှ တူပါမယ်။ ကျွန်တော် မမှတ်မိတော့လို့ပါ)​ လူတစ်ယောက် မွေးလာတာ၊ ကျောင်းတက်တာ၊ အလုပ်လုပ်တာ၊ အိုသွားတာ စသည်ဖြင့် အစဉ်လိုက် နောက်ပြန်မလှည့်ပဲ သွားတာမျိုးကို Linear State လို့ ခေါ်ပါတယ်။ ကျွန်တော်တို့ Data Table တွေမှာ မှတ်ရင်တော့ Encapsulated State အနေနဲ့ Hard Coded လုပ်ပြီး ချိန်းသွားတာမျိုးနဲ့ မှတ်လို့ရပါတယ်။

Non-linear States
Non-linear States တွေကတော့ Business Requirement တွေအပေါ်မှာ မူတည်တာ များပါတယ်။ Drafted State ဆိုရင် Non-linear State လို့ ခေါ်လို့ရပါတယ်။
အဲဒီအပြင် ကျွန်တော်တို့ Approved ဆိုတဲ့ State မှာတင် Manager Approved လား၊ GM Approved လား၊ CEO Approved လားဆိုပြီးကွဲပါသေးတယ်။ အဲဒီလို Linear မဟုတ်တဲ့ အပြန်အလှန်သွားနေတဲ့ ပြောင်းလဲနေတဲ့ State တွေကို Non-linear State​ တွေလို့ ခေါ်လို့ရမယ်ထင်ပါတယ်။ (ဒီနေရာမှာ Dynamic States တွေလို့လဲ ပြောလို့ရမယ်ထင်တယ်။ SE အရ​ ဘယ်လိုခေါ်လဲဲ ကျွန်တော် မမှတ်မိတော့လို့ပါ)

Classification of States
State တွေကို တစ်ခြားနည်းတစ်ခုနဲ့ ခွဲကြည့်မယ်ဆိုရင်
- Business States
- Technical States
ဆိုပြီးခွဲလို့ရပါသေးတယ်။ Business States ကတော့ အချိန်ပြည့် အပြောင်းအလဲရှိနေတဲ့ State တွေကို ပြောတာပါ။ ဉပမာ — approved ဆိုပါစို့။ 
approved_by_sales_person ဆိုတာလဲ ရှိနိုင်သလို approved_by_sales_admin ဆိုတာလဲ ရှိနိုင်ပါတယ်။ ဒါပေမယ့် business requirement အရ approved_by_sales_person ဆိုတာကို ဖြုတ်လိုက်တာလဲ​ ဖြစ်နိုင်သလို approved_by_manager ဆိုတာ ထပ်ထည့်နေတာလဲ​ ဖြစ်နိုင်ပါတယ်။ အစီအစဉ်ပြောင်းသွားတာလဲ ဖြစ်နိုင်ပါတယ်။ အဲဒီလို business requirement အရ အချိန်ပြည့် ပြောင်းလဲနေတဲ့ state တွေကို business states တွေလို့ ကျွန်တော် ယူဆပါတယ်။
Architecture သမားအနေနဲ့ business state တွေဆိုတာ အမြဲတမ်းပြောင်းလဲနေမယ်လို့ သိထားဖို့လိုပါတယ်။ အဲဒါကို မင်းက အချိန်ပြည့် ပြောင်းနေတာပဲလို့ သွားအပြစ်တင်လို့မရပါဘူး။ business မှာ profit making အရ အမျိုးမျိုး ပြောင်းလဲ ထိုးဖောက်နေမှာ ထုံးစံပဲဖြစ်ပါတယ််။ ကိုယ်တွေကသာ အမြဲပြောင်းလဲနေမယ်လို့ သဘောထားပြီး ပြင်ဆင်တည်ဆောက်ထားဖို့ လိုပါတယ်။
နောက်တစ်ခုကတော့ technical state တွေပါ။ created_at တို့ updated_at တို့ deleted_at တို့စတာတွေက technical states တွေလို့ ဆိုနိုင်ပါတယ်။

Mapping between business states and technical states
Business state တွေက အချိန်ပြည့် ပြောင်းလဲနေမှာ ဖြစ်တဲ့အတွက် Data တွေကို ကိုင်တွယ်တဲ့အခါ Consistency Issue ရှိလာပါတယ်။ အဲဒီအတွက် အပြောင်းအလဲမရှိတဲ့ technical states တွေနဲ့ ဒေတာတွေကို ကိုင်တွယ်ရပါတယ်။ အဲဒီမှာ business states တွေနဲ့ technical states တွေကြားမှာ Mapping လုပ်ဖို့ လိုလာပါတယ်။ တစ်ခုခု အပြောင်းအလဲရှိရင် အဲဒီ Mapping တွေကို ချိန်းလိုက်တာနဲ့ Data Consistency ရှိရှိ ရှေ့ဆက်သွားနိုင်အောင် ပြင်ဆင်ထားဖို့ လိုပါတယ်။
ဒီအပိုင်းကတော့ Architecture အပိုင်းမှာ အတော်လေးကို ခက်ခဲတဲ့အပိုင်းလို့ ပြောရပါမယ်။ Deterministic ဖြစ်အောင် သေသေချာချာ Mapping ချနိုင်ဖို့ လိုပါတယ်။ Business States တွေက Non-deterministic တွေ ဖြစ်ပါတယ်။ ဒါပေမယ့် Technical States တွေကတော့ Deterministic ဖြစ်ဖို့ လိုကိုလိုပါတယ်။
ဉပမာ အနေနဲ့ ပြောရမယ်ဆိုရင် approved ဆိုတဲ့ states ကိုပဲ ရှေ့ဆက်လေ့လာကြည့်ပါမယ်။
approved_by_sales_person ဆိုတဲ့ business state ကို technical state အရ approved ဆိုတဲ့ state ရယ်၊ user ရယ်၊ အဲဒီ user ရဲ့ role​ ရယ်တွဲပြီး Mapping လုပ်ထားဖို့ လိုပါတယ်။ audit အနေနဲ့ပဲ မှတ်မလား၊ history အနေနဲ့ပဲ မှတ်မလား မှတ်ထားဖို့ လိုပါတယ်။ အဲဒီနေရာမှာ approved_by_sales_admin ဆိုတာလေး ပြောင်းချင်တယ်ဆိုရင် user ရဲ့ role ကို ချိန်းလိုက်ရုံပါပဲ။ ဒါကတော့ တကယ့် business system ကြီးတွေကို Design ချတဲ့အခါ စဉ်းစားစရာတွေ အများကြီး ရှိပါတယ်။

State Dependencies
State တစ်ခုနဲ့ တစ်ခု ကူးပြောင်းတဲ့အခါ State Dependencies တွေ လိုလာပါတယ်။ ဒီနေရာမှာလဲ
- Linear Dependency
- Non-linear Dependency
ဆိုပြီး နှစ်မျိုးခွဲလို့ရပါတယ်။ Linear Dependency တွေကတော့ ရှင်းပါတယ်။ Approved ပြီးမှ Disbursed သွားလို့ရမယ်ဟာမျိုးတွေပါ။ Non-linear Dependeny တွေမှာတော့ Multiple Dependency နဲ့ Complex Dependency ဆိုပြီး နှစ်မျိုးရှိပါတယ်။ State တစ်ခုဟာ State နှစ်ခု (သို့)​နှစ်ခုထက် ပိုပြီး Dependent ဖြစ်နေရင် Multiple Dependency လို့ခေါ်နိုင်ပြီး State တစ်ခုဟာ State တစ်ခုကို မှီချင်လဲမှီမယ်၊ မမှီချင်လဲမမှီဘူး၊ နှစ်ခုမှာ တစ်ခုကို မှီချင်မှီမယ် မမှီချင် မမှီဘူးဆိုတာတွေကတော့ Complex Dependency လို့ ခေါ်နိုင်ပါတယ်။ Complex Dependency တွေကတော့ SaaS တွေ ရေးတဲ့အခါမှာ ကြုံလာရနိုင်ပါတယ်။ Complex Dependency ဆိုတဲ့အတိုင်း Architecture ချတဲ့နေရာမှာလဲ အင်မတန် Complex ဖြစ်ပါတယ်။

Before & After
ဒါကတော့ State တစ်ခုကို မချိန်းခင်နဲ့ ချိန်းပြီးတဲ့အချိိိန် ဘာတွေ လုပ်ပေးရမလဲ သတ်မှတ်တာတွေပါ။ Rules တွေ ဖြစ်နိုင်တယ်။ Process တွေ ဖြစ်နိုင်တယ်။ filter တွေ ဖြစ်နိုင်တယ်။ အစုံဖြစ်နိုင်ပါတယ်။

State Lock/Unlock
ဒါကတော့ State တစ်ခုနဲ့ တစ်ခုကြားမှာ Lock နဲ့ သွားမယ်ဆိုရင် ဒီတစ်ခု မချိန်းပဲ နောက်တစ်ခု သွားလို့ရမှာ မဟုတ်ပါဘူး။ Unlock ဆိုရင်တော့ သွားလို့ရပါမယ်။ အဲဒီ Lock/Unlock တွေဆိုတာကို Flow နဲ့လဲ တွဲလို့ရပါတယ်။ Flow လို့ ပြောလိုက်ရင် Orchestration တွေပါ ပါလာမှာ ဖြစ်တဲ့အတွက် အများကြီး မပြောတော့ပါဘူး။

Service Oriented Architecture and Data States
Service Oriented Architecture တွေမှာ Data State​ တွေက သိပ်ကို အရေးပါပါတယ်။ Service တစ်ခုနဲ့ တစ်ခုကြား Contract တွေ သတ်မှတ်ရတဲ့အခါ ဘယ် Data ကတော့ဖြင့် ဘယ် state မှာ ငါကလက်ခံမယ်ဆိုတာမျိုးတွေ သေသေချာချာ သတ်မှတ်ဖို့ လိုပါတယ်။ မဟုတ်ရင် Service တွေဟာ တစ်ခုနဲ့တစ်ခု မပြတ်တော့ပဲ ပုံမှန် Monolith ရေးတာထက်ကို ပိုပြီးရှုပ်ထွေးသွားနိုင်ပါတယ်။