3.2 فن تعمیر کے اسالیب اور نمونے

جائزہ اور محرکات

فن تعمیر کا اسلوب نظام کو منظم کرنے کی وسیع، دوبارہ قابل استعمال شکل ہے: اسے کیسے تقسیم کیا جاتا ہے، حصے آپس میں کیسے رابطہ کرتے ہیں، اور حدیں کہاں پڑتی ہیں۔ اسے چننا بڑے ادارے کے سب سے نتیجہ خیز (اور سب سے زیادہ غلط سمجھے جانے والے) فیصلوں میں سے ہے۔ اکثر انتخاب ٹیم، ڈومین، اور آپریشنل حقیقت کی اصل پابندیوں کی بجائے فیشن کے پیچھے چلتا ہے (“ہر کوئی مائیکرو سروسز کر رہا ہے”)۔ آپ دو گڑبڑوں میں سے ایک میں پہنچتے ہیں: ایسا تقسیم شدہ نظام جسے ادارہ چلا نہیں سکتا، یا الجھا ہوا یک سنگی نظام جسے کوئی محفوظ طریقے سے بدل نہیں سکتا۔ دونوں اسلوب کا قصور نہیں۔ دونوں اسلوب کو صورت حال سے بے جوڑ ملانے سے آتی ہیں۔

بڑی ڈویلپر ٹیموں کے لیے اسالیب سب سے زیادہ کونوے کے قانون کی وجہ سے اہم ہیں: نظام کی ساخت اس ادارے کے رابطے کے ڈھانچے کی عکاسی کرتی ہے جو اسے بناتا ہے۔ تو فن تعمیر کا اسلوب تنظیمی ڈیزائن کا فیصلہ بھی ہے۔ نظام کو سروسز میں تقسیم کرنا دراصل ٹیموں، ملکیت، اور آن کال ذمہ داری کی تقسیم کا فیصلہ ہے۔ سینکڑوں انجینئروں والے انٹرپرائز آزادانہ تعیناتی کے ساتھ باریک سروسز برداشت کر سکتے ہیں (اور اکثر انہیں ضرورت ہے)، کیونکہ یہی آزادی بہت سی ٹیموں کو ایک دوسرے کو روکے بغیر ریلیز کرنے دیتی ہے۔ وہی نمونہ ایک چھوٹی ٹیم پر مسلط کریں تو وہ تمام آپریشنل محصول وراثت میں پاتی ہے اور تنظیمی فائدہ کچھ نہیں۔

حکومت اور انٹرپرائز کی ترتیبیں مزید پابندیاں ڈھیر کرتی ہیں: نظاموں کی طویل عمر، سخت تبدیلی کا کنٹرول، خریداری کے چکر، ریکارڈ کے جمے ہوئے نظاموں سے انضمام، اور آڈٹ کی اہلیت۔ یہ ان اسالیب کے حق میں ہیں جو حدیں واضح اور انحصارات کو جانچنے میں آسان رکھتے ہیں۔ یہ باب بڑے اسالیب کا جائزہ لیتا ہے: یک سنگی سے مائیکرو سروسز تک، CQRS اور ایونٹ سورسنگ کے ساتھ ایونٹ پر مبنی فن تعمیر، سروس میش اور گیٹ ویز کے نمونے، سرور لیس، اور ہیکساگونل اور صاف فن تعمیر کے اندرونی نظم و ضبط۔ اس سے بڑھ کر، یہ آپ کو بتانے میں مدد کرتا ہے کہ ہر ایک کب موزوں ہے۔

مزید دیکھیں: باب 2.2 (سافٹ ویئر ڈیزائن کے اصول، بشمول ڈومین ڈرائیون ڈیزائن)، باب 3.1 (فن تعمیر کی بنیادیں)، اور باب 3.3 (تقسیم شدہ نظام)۔

بنیادی اصول

اسلوب قوتوں کی پیروی کرتا ہے، فیشن کی نہیں۔ ٹیم کے سائز، ڈومین کی پیچیدگی، بوجھ، اور آپریشنل پختگی کی بنیاد پر چنیں، کبھی اس لیے نہیں کہ ٹیکنالوجی مقبول ہے۔
جوڑ اصل دشمن ہے، قابل تعیناتی اکائیوں کی تعداد نہیں۔ اچھی طرح ماڈیولر یک سنگی نظام تقسیم شدہ بڑے کیچڑ کے گولے سے بہتر ہے۔
تقسیم آزادی کے لیے ادا کی جانے والی لاگت ہے۔ صرف تب تقسیم کریں جب آزادانہ تعیناتی، پیمائش، یا ناکامی کی تنہائی کی قدر نیٹ ورک کالز، جزوی ناکامی، اور سروسز کے پار ڈیٹا کی مطابقت کی لاگت سے زیادہ ہو۔
حدیں کاروباری ڈومین کی پیروی کریں۔ سروسز اور ماڈیولز کو محدود سیاق (ہر ایک اپنی واضح حد کے ساتھ خود مکتفی ڈومین ماڈل) کے ساتھ ہم آہنگ کریں، تکنیکی تہوں کے ساتھ نہیں۔
باہر کچھ بھی ہو، اندر کو اچھی طرح ڈیزائن کریں۔ ہیکساگونل/صاف تہہ بندی ہر اسلوب میں کاروباری منطق کو فریم ورک اور انفراسٹرکچر سے آزاد رکھتی ہے۔
کونوے کا قانون ناگزیر ہے، اس لیے اسے استعمال کریں۔ ٹیم کی حدیں اور فن تعمیر ساتھ ڈیزائن کریں۔
جتنا سمجھتے ہیں اس سے سادہ شروع کریں۔ آپ اچھے ماڈیولر یک سنگی نظام سے سروسز نکال سکتے ہیں؛ قبل از وقت مائیکرو سروسز کی گڑبڑ کو دوبارہ غیر تقسیم کرنا کہیں مشکل ہے۔

سفارشات

ماڈیولر یک سنگی نظام سے شروع کریں؛ شہادت کے ساتھ تقسیم کریں

زیادہ تر نظام ایک ہی قابل تعیناتی اکائی کے طور پر مضبوط اندرونی ماڈیول کی حدوں کے ساتھ شروع کریں: واضح انٹرفیس، کسی دوسرے ماڈیول کے ڈیٹا میں ہاتھ ڈالنا نہیں، اور نافذ شدہ انحصار کے اصول۔ آپ کو سادہ ٹرانزیکشنز، آسان ری فیکٹرنگ، اور ایک ہی چیز ملتی ہے جسے تعینات اور مشاہدہ کرنا ہے۔ ماڈیول کو اپنی سروس میں صرف تب الگ کریں جب ٹھوس وجہ ہو: ایسا حصہ جسے خود پیمائش کرنی ہو، ایسی ٹیم جسے اپنی رفتار سے تعینات کرنا ہو، ناکامی کا دائرہ جسے الگ کرنا ہو، یا باقی سے مختلف ٹیکنالوجی کا تقاضا۔ جب آپ تقسیم کریں تو محدود سیاق کی لکیروں پر تقسیم کریں تاکہ ہر سروس اپنے ڈیٹا کی مالک ہو اور مستحکم معاہدہ ظاہر کرے۔

جانیں مائیکرو سروسز اپنی جگہ کب کماتی ہیں

مائیکرو سروسز آپ کو آزادانہ قابل تعیناتی، آزادانہ پیمائش، ناکامی کی تنہائی، اور ٹیکنالوجیز ملانے کی آزادی دیتی ہیں۔ بدلے میں وہ پختہ CI/CD (مسلسل انضمام اور مسلسل ترسیل)، خودکار انفراسٹرکچر، تقسیم شدہ ٹریسنگ، سروس کی دریافت، اور آن کال ثقافت کا تقاضا کرتی ہیں۔ ایمانداری سے خود سے پوچھیں: کیا آپ کا ادارہ درجنوں آزادانہ تعینات سروسز پروڈکشن میں قابل اعتماد طور پر چلا سکتا ہے؟ اگر پلیٹ فارم اور آپریشنل پختگی موجود نہیں تو مائیکرو سروسز اپنے فوائد پہنچائے بغیر آپ کی ناکامی کے طریقے بڑھاتی ہیں۔ بہت سے ادارے ننھی سروسز کے جھنڈ کی بجائے بڑے ڈومینز سے ہم آہنگ مٹھی بھر موٹی سروسز کے ساتھ بہترین کرتے ہیں۔

ایونٹ پر مبنی فن تعمیر وہاں استعمال کریں جہاں جوڑ ڈھیلا کرنا اور غیر ہم وقتی ثمر دے

ایونٹ پر مبنی فن تعمیر پیدا کرنے والوں کو حقائق خارج کرنے دیتا ہے بغیر جانے کہ انہیں کون استعمال کرتا ہے۔ یہ ڈھیلا جوڑ، بوجھ کے اچھال کے لیے بفر، اور نئے صارفین جوڑنے کا آسان طریقہ خریدتا ہے۔ اسے وہاں استعمال کریں جہاں ورک فلو قدرتی طور پر غیر ہم وقت اور ردعملی ہوں۔ CQRS (Command Query Responsibility Segregation) لکھنے کے ماڈل کو ایک یا زیادہ پڑھنے کے ماڈلز سے الگ کرتا ہے، جو تب مدد کرتا ہے جب پڑھنے اور لکھنے کے بوجھ یا شکلیں شدت سے مختلف ہوں۔ ایونٹ سورسنگ حالت کو موجودہ حالت کے بجائے ایونٹس کے صرف اضافہ ہونے والے لاگ کے طور پر محفوظ کرتی ہے، آپ کو بہترین آڈٹ کا نشان اور وقت میں سفر دیتی ہے۔ یہ مالیات اور حکومت کے لیے طاقتور ہے، جہاں “ہم اس قدر تک کیسے پہنچے؟” قانونی سوال ہے، مگر ایونٹس کی ورژننگ، پروجیکشنز کی دوبارہ تعمیر، اور حتمی مطابقت پر استدلال میں حقیقی پیچیدگی جوڑتی ہے۔ ان تک جان بوجھ کر پہنچیں، بذریعہ ڈیفالٹ نہیں۔

بہت سی سروسز سنبھالنے کے لیے گیٹ وے، BFF، اور میش کے نمونے لاگو کریں

API گیٹ وے بیرونی کلائنٹس کو واحد داخلی نقطہ دیتا ہے، تصدیق، شرح کی حد، روٹنگ، اور TLS (Transport Layer Security) ٹرمینیشن سنبھالتا ہے۔ Backend-for-Frontend (BFF) ہر کلائنٹ قسم (ویب، موبائل، شراکت دار API) کو اپنی موزوں مجموعی تہہ دیتا ہے، تاکہ آپ سب پر ایک ناپ کے پھولے ہوئے API سے بچیں۔ سروس میش ہمہ گیر معاملات (باہمی TLS، دوبارہ کوششیں، ٹائم آؤٹ، ٹریفک کی منتقلی، اور ٹیلی میٹری) کو سائیڈ کار انفراسٹرکچر کی تہہ میں لے جاتا ہے، تاکہ ایپلیکیشن ٹیموں کو انہیں دوبارہ نافذ نہ کرنا پڑے۔ میش صرف تب جوڑیں جب سروسز کی تعداد ان معاملات کو فی سروس سنبھالنا ناقابل انتظام بنا دے۔ چند سروسز کے لیے میش اپنی قدر سے زیادہ آپریشنل وزن ہے۔

سرور لیس کو ایمانداری سے تولیں

Function-as-a-service اور منظم سرور لیس پلیٹ فارمز سرور کا انتظام آپ کی پلیٹ سے اتار دیتے ہیں، صفر تک پیمائش کرتے ہیں، اور استعمال کے حساب سے بل بناتے ہیں، جو اچھال والے، ایونٹ پر مبنی، یا کم بنیادی خط والے بوجھ اور چھوٹی ٹیموں کے لیے بہترین ہے۔ سمجھوتے حقیقی ہیں: کولڈ اسٹارٹ کی لیٹنسی، عمل درآمد کے وقت اور وسائل کی حدیں، مقامی ٹیسٹنگ کی مشکل، ممکنہ فروخت کنندہ کی قید، اور لاگت جو مسلسل زیادہ حجم پر فراہم کردہ انفراسٹرکچر سے بڑھ سکتی ہے۔ سرور لیس وہاں استعمال کریں جہاں اس کی معاشیات اور آپریشنل سادگی واضح طور پر جیتیں۔ مستحکم، اعلیٰ تھرو پٹ بنیادی نظاموں کو جوش میں اس میں مت ٹھونسیں۔

ہر سروس کے اندر کاروباری منطق کو صاف رکھیں

بیرونی اسلوب کچھ بھی ہو، اندر کو ہیکساگونل (پورٹس اور اڈاپٹرز) یا صاف فن تعمیر سے صاف رکھیں: کاروباری قواعد مرکز میں، صرف تجریدات پر منحصر؛ فریم ورکس، ڈیٹا بیس، اور پیغام رسانی کناروں پر بدلنے کے قابل اڈاپٹرز کے طور پر۔ یہ آپ کی قیمتی ڈومین منطق کو انفراسٹرکچر کے بغیر قابل ٹیسٹ اور ٹیکنالوجی کی تبدیلیوں کے پار قابل منتقلی رکھتا ہے: طویل العمر سرکاری اور انٹرپرائز نظاموں کے لیے فیصلہ کن برتری جو فریم ورکس کی کئی نسلوں سے زیادہ جئیں گے۔

سمجھوتے: فوائد اور نقصانات

اسلوب	کب بہترین	فوائد	نقصانات
ماڈیولر یک سنگی	زیادہ تر نظام، خاص طور پر ابتدا میں	سادہ آپریشنز، آسان ٹرانزیکشنز اور ری فیکٹرنگ	واحد تعیناتی اکائی؛ ایک کے طور پر پیمائش؛ کٹاؤ کا خطرہ
مائیکرو سروسز	بہت سی ٹیمیں، اعلیٰ پیمانہ، پختہ پلیٹ فارم	آزادانہ تعیناتی/پیمائش، ناکامی کی تنہائی	تقسیم شدہ پیچیدگی، ڈیٹا کی مطابقت، اعلیٰ آپریشنز کی لاگت
ایونٹ پر مبنی / CQRS / ایونٹ سورسنگ	غیر ہم وقت ورک فلو، آڈٹ کی ضرورت، مختلف پڑھنا/لکھنا	ڈھیلا جوڑ، آڈٹ کی اہلیت، قابل پیمائش پڑھنا	حتمی مطابقت، ایونٹ کی ورژننگ، مشکل ڈی بگنگ
سرور لیس	اچھال والا یا کم بنیادی خط، ایونٹ پر مبنی کام	سرور کا انتظام نہیں، صفر تک پیمائش، استعمال کے حساب سے ادائیگی	کولڈ اسٹارٹ، حدیں، قید، اعلیٰ مستحکم بوجھ پر لاگت

بار بار آنے والا موضوع: آپ لچک اور آزادی آپریشنل اور ذہنی پیچیدگی سے خریدتے ہیں۔ تقسیم شدہ اور ایونٹ پر مبنی اسالیب واحد کال اسٹیک اور واحد ٹرانزیکشن کی سادگی چھوڑ دیتے ہیں اس صلاحیت کے بدلے کہ آزادانہ پیمائش، تعیناتی، اور ناکامی ہو۔ یہ سودا پیمانے پر اور پختہ پلیٹ فارم کے ساتھ ثمر دیتا ہے۔ اس کے بغیر یہ تباہ کن ہے۔ اندرونی نظم و ضبط (ہیکساگونل/صاف) تقریباً ہمیشہ قابل قدر ہیں، کیونکہ وہ تھوڑی لاگت لیتے ہیں اور آپ کے اختیارات کھلے رکھتے ہیں کہ بعد میں اسالیب بدل سکیں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

اگلی سروس الگ کرنے سے پہلے، کیا آپ اس کی مالک ٹیم کو بھی الگ کریں گے، اور یہ کرنے کا اختیار کس کے پاس ہے؟ کونوے کے قانون کا مطلب ہے کہ سروس کی حد دراصل ٹیم کی حد ہے، اس لیے ایسی تقسیم جس کی تنظیمی چارٹ حمایت نہ کرے تقسیم شدہ یک سنگی نظام پیدا کرتی ہے: دو قابل تعیناتی اکائیاں، ایک ریلیز ٹرین، مشترک آن کال۔ بڑے انٹرپرائز میں ٹیموں کو نئی شکل دینے کا اختیار عموماً انجینئرنگ سے اوپر ہوتا ہے، رپورٹنگ لائنوں، مالیات، اور HR کے پاس، اسی لیے فن تعمیر اور تنظیمی ڈیزائن کا فیصلہ ساتھ ہونا چاہیے۔ بحث میں شہادت لائیں: کیا مجوزہ سروس کی ایسی ٹیم ہے جو اسے شروع سے آخر تک اپنا سکے، اپنی آن کال سنبھالے، اور اپنی رفتار سے تعینات کرے؟ اگر جواب نہیں ہے تو یا ٹیم کو فنڈ کریں یا صلاحیت کو یک سنگی نظام میں ماڈیول کے طور پر رکھیں۔ ملکیت کی تقسیم کے بغیر کوڈ کو تقسیم کرنا تقسیم کی ہر لاگت خریدتا ہے اور آزادی کی کوئی نہیں۔
کیا آپ آج اپنی ہر سروس کو آزادانہ تعینات کر سکتے ہیں، یا وہ خفیہ طور پر ایک ساتھ بھیجی جاتی ہیں؟ تقسیم شدہ یک سنگی نظام اس باب کا بدترین نتیجہ ہے: آپ نیٹ ورک کالز، جزوی ناکامی، اور سروسز کے پار ڈیٹا کی مطابقت کی قیمت دیتے ہیں، پھر بھی ایک کو دوسروں کے بغیر ریلیز نہیں کر سکتے۔ واضح نشانیاں مشترک ڈیٹا بیس، مشترک لائبریری جو ہم آہنگ اپ گریڈ مجبور کرتی ہے، اور انضمام کے ٹیسٹ ہیں جو پوری جائیداد کو ایک ساتھ چلانے ہوتے ہیں۔ بڑی ٹیم کے لیے یہ خاموشی سے تھرو پٹ محدود کرتا ہے، کیونکہ ہر ٹیم ایک ہی ریلیز کے پیچھے قطار میں ہے جبکہ خاکہ آزادی دکھاتا ہے۔ ایک حالیہ تبدیلی لیں اور گنیں کہ اسے محفوظ بنانے کے لیے کتنی سروسز کو ایک ساتھ تعینات کرنا پڑا؛ اگر ایک ہی صلاحیت کو چھونے والی تبدیلی کے لیے وہ عدد ایک سے زیادہ ہو تو آپ کی حدیں غلط ہیں۔ اصلاح عموماً ہر سروس کو اپنا ڈیٹا اور مستحکم، ورژن شدہ معاہدہ دینا ہے، مزید سروسز جوڑنا نہیں۔
آپ کی موجودہ سروس کی کون سی تقسیمیں ثمر دینا بند کر چکی ہیں، اور کیا آپ انہیں واپس یکجا کریں گے؟ باب کی سب سے ترقی یافتہ عادت اسلوب کے فیصلوں کو الٹنے کے قابل سمجھنا ہے: جب محرک ظاہر ہو تو نکالیں، اور جب محرک غائب ہو تو دوبارہ ضم کریں۔ زیادہ تر ادارے صرف تقسیم کرتے ہیں، تو نینو سروسز اور بکواسی ہستی سروسز تب تک جمع ہوتی ہیں جب تک آرکسٹریشن اور نیٹ ورک کا اضافی بوجھ ہر سروس کے کام سے بڑھ جائے۔ ایسی سروسز ڈھونڈیں جو ہمیشہ ایک ساتھ تعینات ہوتی ہیں، جو کاروباری صلاحیت کی بجائے ڈیٹا بیس ٹیبل کی وجہ سے موجود ہیں، یا جن کے نیٹ ورک ہاپس اب درخواست کی لیٹنسی پر غالب ہیں۔ انٹرپرائز اور سرکاری جائیدادوں میں، جہاں عملے اور بجٹوں کی جانچ ہوتی ہے، دو پتلی سروسز کو ایک موٹی سروس میں واپس تہہ کرنا جائز، لاگت بچانے والا قدم ہے، ناکامی کا اعتراف نہیں۔ دوبارہ یکجا کرنا اتنی ہی کھل کر میز پر رکھیں جتنا نکالنا، اور دونوں کا فیصلہ ایک ہی شہادت سے کریں۔
کیا آپ کا پلیٹ فارم اور آن کال کی پختگی واقعی اس اسلوب کو سہارا دیتی ہے جو آپ تجویز کر رہے ہیں، اور کیا آپ عہد کرنے سے پہلے مخصوص خلا کا نام لے سکتے ہیں؟ مائیکرو سروسز، میش، اور ایونٹ پر مبنی ریڑھ کی ہڈیاں اپنے فوائد صرف پختہ CI/CD، تقسیم شدہ ٹریسنگ، سروس کی دریافت، اور ایسی آن کال ثقافت کے اوپر پہنچاتی ہیں جو جزوی ناکامی پر استدلال کر سکے۔ بڑا ادارہ ہدف اسلوب فن تعمیر کے فورم میں طے کرتا ہے اور غائب پلیٹ فارم بعد میں دریافت کرتا ہے، جب درجنوں سروسز پہلے ہی پروڈکشن میں ہیں اور ہر واقعے کی تشخیص گھنٹے لیتی ہے۔ آزادانہ تعیناتی اور پیمائش کی کشش کو اس سنجیدہ سوال کے مقابل تولیں کہ صبح 3 بجے اسے کون چلاتا ہے: وہی تقسیم جو ٹیموں کو متوازی طور پر ریلیز کرنے کے لیے آزاد کرتی ہے ناکامی کے وہ طریقے بھی بڑھاتی ہے جو ہر ٹیم کو سمجھنے ہیں۔ بحث میں ایماندار فہرست لائیں: موجودہ تعیناتی کی تعدد، بحالی کا اوسط وقت، آیا آپ کے پاس سروس کی حدوں کے پار ٹریسنگ ہے، اور ایک ٹیم حقیقت پسندی سے کتنی سروسز چلا سکتی ہے۔ انٹرپرائز اور سرکاری ترتیبوں میں ان پلیٹ فارم صلاحیتوں کے لیے خریداری اور بھرتی کا وقت شامل کریں جو آپ میں نہیں ہیں، کیونکہ جو اسلوب ایسے میش اور پلیٹ فارم ٹیم کو فرض کرے جسے آپ نے فنڈ نہیں کیا وہ ناقابل سپورٹ جائیداد چلانے کا منصوبہ ہے۔
ڈومین کے کن حصوں کے لیے مکمل ایونٹ سورس آڈٹ کا نشان تکلف کی بجائے قانونی ضرورت ہے، اور فیصلے کا اختیار کس کو ہے؟ ایونٹ سورسنگ اور CQRS آپ کو بہترین، دوبارہ تعمیر ہونے والی تاریخ اور ایسے پڑھنے کے ماڈل خریدتے ہیں جو خود پیمائش کرتے ہیں، مگر نظام کی زندگی بھر ایونٹ کی ورژننگ، پروجیکشن کی دوبارہ تعمیر، اور حتمی مطابقت پر استدلال کی لاگت لیتے ہیں۔ ایسے ڈومین پر لاگو کریں جسے آڈٹ کا نشان کبھی نہیں چاہیے تھا تو وہ پیچیدگی خالص محصول ہے؛ ایسے ڈومین سے روکیں جہاں “ہم اس قدر تک کیسے پہنچے؟” قانونی سوال ہے تو اس کی غیر موجودگی تعمیل کی ناکامی ہے۔ متصادم غور ایک طرف آڈٹ کی اہلیت اور سوال کی وسعت پذیری ہیں، دوسری طرف ڈی بگنگ کی مشکل اور ڈویلپر کا ذہنی بوجھ، اس لیے فیصلہ ان کا ہونا چاہیے جو ضابطے کی ذمہ داری اور آپریشنل بوجھ دونوں سمجھتے ہیں، اس کا نہیں جو نمونے پر سب سے زیادہ پرجوش ہے۔ مخصوص قانونی یا معاہداتی برقراری اور دوبارہ تعمیر کے تقاضے، متوقع ایونٹس کا حجم، اور ورژننگ اور پروجیکشن کے کام کا ایماندار اندازہ لائیں۔ مالیات، ٹیکس، اور حکومت میں، جہاں برسوں بعد فیصلے کی دوبارہ تعمیر قانونی فریضہ ہو سکتی ہے، جوابدہ مالک کا نام لیں جو دستخط کرتا ہے کہ دیے گئے محدود سیاق کو ناقابل تبدیل ایونٹ لاگ چاہیے یا نہیں۔
آپ ماڈیولر یک سنگی نظام کو کٹاؤ سے کیسے روکیں گے تاکہ بعد میں نکالنا سستا رہے، اور حدیں کیا نافذ کرے گا؟ ماڈیولر یک سنگی نظام سے شروع کرنے کا پورا جواز اس وعدے پر ہے کہ صاف اندرونی حدیں بعد میں سروس کے اخراج کو قابل برداشت بناتی ہیں، پھر بھی وہ حدیں خاموشی سے گلتی ہیں جس لمحے ڈیڈ لائن ایک ماڈیول کو دوسرے کے ڈیٹا میں ہاتھ ڈالنے پر اکسائے۔ بہت سے شراکت کاروں والی بڑی ٹیم کے لیے اچھی نیتیں اور کوڈ ریویو اکیلے لکیر نہیں سنبھالیں گے؛ نافذ کرنے والے طریقے کے بغیر یک سنگی نظام خاموشی سے وہی بڑا کیچڑ کا گولا بن جاتا ہے جس سے بچنے کے لیے اسلوب بنا تھا۔ نافذ شدہ انحصار کے اصولوں اور ماڈیول انٹرفیسز کی رگڑ کو برسوں بعد دریافت کرنے کی لاگت کے مقابل تولیں کہ کوئی حد حقیقی نہیں اور ہر اخراج کا مطلب مشترک حالت کو الجھن سے نکالنا ہے۔ شہادت لائیں: کیا ماڈیول کی حدیں بلڈ ٹولنگ، جامد تجزیے، یا پیکیج کی ساخت سے نافذ ہیں، یا محض دستاویزی رواج ہیں جنہیں پچھلے چھ انضمام نے نظر انداز کیا؟ طویل العمر انٹرپرائز اور سرکاری نظاموں میں جنہیں سخت تبدیلی کے کنٹرول اور فریم ورکس کی کئی نسلوں سے بچنا ہے، حدوں کے نفاذ کو قابل آڈٹ کنٹرول سمجھیں، تاکہ بعد میں تقسیم کرنے کا اختیار وہ ہو جو آپ نے واقعی محفوظ رکھا ہو، نہ کہ وہ جو آپ فرض کرتے ہیں کہ اب بھی آپ کے پاس ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ واحد ماڈیولر یک سنگی نظام کو ڈیفالٹ بنائیں اور مائیکرو سروسز کی کشش کی مزاحمت کریں، کیونکہ آپ کا کم یاب ترین وسیلہ انجینئرنگ کی توجہ ہے اور سروسز کا جھنڈ آپریشنل محصول ہے جو آپ پروڈکٹ اور مارکیٹ کی ہم آہنگی سے پہلے برداشت نہیں کر سکتے۔ بعد میں نکالنے کے لیے صاف ماڈیول کی حدیں رکھیں، اور سرور لیس تک وہاں پہنچیں جہاں صفر تک پیمائش اور استعمال کے حساب سے ادائیگی آپ کے اچھال والے، کم بنیادی خط کے بوجھ کو موزوں ہو۔ ٹھیک ایک چیز تب الگ کریں جب ٹھوس محرک ظاہر ہو، جیسے اچھال والا نوٹیفکیشن بھیجنے والا، اور اس سے پہلے کبھی نہیں۔

چھوٹا کاروبار۔ پلیٹ فارم ٹیم کے بغیر اور تنگ بجٹ کے ساتھ یک سنگی نظام یا منظم پلیٹ فارم پر مٹھی بھر موٹی سروسز کو ترجیح دیں، اور میش، ٹریسنگ، اور سروس کی دریافت خود بنانے کی بجائے میزبانی والا انفراسٹرکچر خریدیں۔ سرور لیس اور منظم ڈیٹا بیس کو سرور چلانے سے مکمل بچنے کے طریقے کے طور پر تولیں، اور ایسے تقسیم شدہ ڈیزائن سے ہوشیار رہیں جس کا آپریشنل بوجھ اٹھانے کو آپ کے پاس کوئی نہ ہو۔ درست فن تعمیر وہ ہے جسے ایک یا دو افراد دراصل تعینات، مشاہدہ، اور بحال کر سکیں۔

بڑا ادارہ۔ اصل مسئلہ بہت سی ٹیمیں اور کونوے کا قانون ہے: موٹی سروسز کو محدود سیاق اور ٹیم کی ملکیت سے ہم آہنگ کریں، اور اس پلیٹ فارم (CI/CD، ٹریسنگ، میش، اور سروس کی دریافت) میں جان بوجھ کر سرمایہ لگائیں جو تقسیم کو محفوظ بناتا ہے۔ گیٹ وے، BFF، اور اندرونی صاف فن تعمیر کے نمونے معیاری بنائیں تاکہ گروہ انہیں دوبارہ ایجاد کرنا بند کریں، اور اخراج اور دوبارہ یکجا کرنے کو مقامی ترجیح کی بجائے شہادت پر مبنی پورٹ فولیو فیصلے کے طور پر منظم کریں۔ ہر تقسیم کی آپریشنل لاگت واضح طور پر بجٹ کریں، کیونکہ آپ کے پیمانے پر تقسیم شدہ یک سنگی ناکامی مہنگی اور اکھاڑنے میں سست ہے۔

حکومت۔ نظاموں کی طویل عمر، سخت تبدیلی کا کنٹرول، خریداری کے چکر، اور آڈٹ کی اہلیت انتخاب کو شکل دیتے ہیں: ان اسالیب کو ترجیح دیں جن کی حدیں واضح، قابل معائنہ ہوں اور معاہدے پائیدار ہوں جو فروخت کنندگان اور فریم ورک کی نسلوں سے زیادہ جئیں۔ ایونٹ سورسنگ اپنی پیچیدگی وہاں کماتی ہے جہاں شہری کی طرف والے فیصلے کی دوبارہ تعمیر قانونی فریضہ ہو، اس لیے اسے بنیادی کھاتوں کے لیے جان بوجھ کر استعمال کریں اور ہر سروس کے اندر صاف فن تعمیر رکھیں تاکہ ہر بجٹ کے ساتھ بدلنے والے قواعد الگ رہیں۔ ملکیتی سرور لیس یا فروخت کنندہ پلیٹ فارمز سے منتقلی اور نکلنے کو خریداری کے تقاضے سمجھیں، بعد کے خیالات نہیں۔

مثالیں

اسٹارٹ اپ۔ شیڈولنگ پروڈکٹ بنانے والا چار افراد کا اسٹارٹ اپ مائیکرو سروسز سے شروع کرنے کے دباؤ کو محسوس کرتا ہے کیونکہ مقابل نے ان کے بارے میں بلاگ لکھا، مگر مزاحمت کرتا ہے۔ وہ واحد ماڈیولر یک سنگی نظام بھیجتے ہیں جس کی صاف اندرونی حدیں ہیں (شیڈولنگ، بلنگ، نوٹیفکیشنز) ایک ہی قابل تعیناتی اکائی میں الگ ماڈیولز کے طور پر، تاکہ ایک انجینئر پورا نظام مقامی طور پر چلا سکے اور ریلیز ایک پش ہو۔ جیسے پروڈکٹ کو گرفت ملتی ہے، صرف نوٹیفکیشن بھیجنے والا، جو اچھال والے بوجھ تلے ای میل اور SMS پر پھیلتا ہے، اپنی سروس میں نکالا جاتا ہے۔ وہ درجن بھر سروسز کا کوئی آپریشنل محصول وراثت میں نہیں پاتے جبکہ وہ ابھی پروڈکٹ اور مارکیٹ کی ہم آہنگی تلاش کر رہے ہیں۔

بڑا ادارہ۔ ایک بڑی ای کامرس کمپنی ماڈیولر یک سنگی نظام سے شروع ہوتی ہے۔ ٹریفک بڑھنے اور ٹیموں کے پھیلنے پر، وہ سب سے زیادہ بوجھ والے اور سب سے آزادانہ ارتقا کرنے والے ڈومینز (کیٹلاگ، کارٹ، چیک آؤٹ، اور تلاش) کو الگ سروسز میں نکالتی ہے، ہر ایک اپنے ڈیٹا کی مالک۔ چیک آؤٹ ایونٹس خارج کرتا ہے جنہیں انوینٹری، فلفلمنٹ، اور تجزیات ایونٹ ریڑھ کی ہڈی کے ذریعے استعمال کرتے ہیں، تاکہ نئے صارفین (فراڈ کی شناخت، وفاداری) چیک آؤٹ کو چھوئے بغیر جڑ سکیں۔ API گیٹ وے تصدیق اور شرح کی حد سنبھالتا ہے، اور BFF موبائل کے لیے پے لوڈ موزوں بناتا ہے۔ باقی کم ٹریفک کے ڈومینز یک سنگی نظام میں رہتے ہیں، جو غیر ضروری ٹکڑے ٹکڑے ہونے سے بچاتا ہے۔

حکومت۔ ٹیکس اتھارٹی بنیادی کھاتے کے لیے ایونٹ سورسنگ پر تشخیص کا پلیٹ فارم بناتی ہے، کیونکہ ٹیکس دہندہ کی ذمہ داری میں ہر تبدیلی برسوں تک قابل دوبارہ تعمیر اور قانونی طور پر قابل آڈٹ ہونی چاہیے۔ کمانڈز (ریٹرن فائل کرو، ادائیگی لاگو کرو، ایڈجسٹمنٹ جاری کرو) ناقابل تبدیل ایونٹس پیدا کرتی ہیں، اور پڑھنے کے ماڈلز افسران اور شہریوں کے لیے موجودہ بیلنس کا پروجیکشن بناتے ہیں۔ CQRS عوامی سوال کی طرف کو فائلنگ کے عروجی موسم کے لیے خود پیمائش کرنے دیتا ہے بغیر لکھنے کی طرف کو خطرے میں ڈالے۔ اندر، ہر سروس صاف فن تعمیر کی پیروی کرتی ہے، اس لیے تشخیص کے قواعد، جو ہر بجٹ کے ساتھ بدلتے ہیں، تسلسل اور پیغام رسانی کی ٹیکنالوجی سے الگ رہتے ہیں۔

کاروباری جواز: محرکات، ROI اور TCO

اسلوب کے انتخاب میں داؤ پر لگی رقم بہت بڑی ہے، کیونکہ فیصلہ الٹنا مہنگا ہے۔ مائیکرو سروسز بہت جلد اپنائیں تو آپ پلیٹ فارم کی تعمیر، نقل شدہ انفراسٹرکچر، تقسیم شدہ ڈی بگنگ، اور بھاری آپریشنز کے بوجھ سے ملکیت کی کل لاگت بڑھاتے ہیں: لاگتیں جو نظام کی زندگی بھر آپ کے ساتھ رہتی ہیں۔ حقیقتاً زائد بوجھ والے یک سنگی نظام کو تقسیم کرنے سے انکار کریں تو آپ ترسیل کا تھرو پٹ محدود کرتے ہیں: ٹیمیں مشترک ریلیز کے پیچھے قطار میں ہوتی ہیں، اور ہر تبدیلی پورے نظام کو خطرے میں ڈالتی ہے۔ ROI کی گفتگو دراصل آپریشنل خرچ کو تنظیمی ضرورت سے ملانے کے بارے میں ہے۔

قیادت کے سامنے دلیل تھرو پٹ اور خطرے کی اصطلاحات میں رکھیں، ٹیکنالوجی کی نہیں۔ آزادانہ قابل تعیناتی کا مطلب ہے زیادہ ٹیمیں متوازی ریلیز کر رہی ہیں اور لیڈ ٹائم کم: قابل پیمائش کاروباری رفتار۔ ناکامی کی تنہائی کا مطلب ہے کل بندشیں کم اور دھماکے کا دائرہ چھوٹا: قابل پیمائش دستیابی اور ساکھ کا تحفظ۔ مگر ہر اسلوب کے مطالبہ کردہ پلیٹ فارم کی سرمایہ کاری کے بارے میں اتنے ہی ایماندار رہیں: میش، ٹریسنگ، اور CI/CD کی پختگی پیشگی شرطیں ہیں، اختیاری اضافے نہیں، اور ان کی لاگت TCO میں شامل ہے۔ بہت سے اداروں کے لیے سب سے سستا راستہ اب اچھی طرح ماڈیولر یک سنگی نظام ہے، صاف اندرونی حدوں کے ساتھ جو بعد میں نکالنا سستا بناتی ہیں۔ یہ آپ کو تقسیم کرنے کا اختیار خریدتا ہے بغیر ضرورت سے پہلے اس کی قیمت دیے۔

ضد نمونے اور خامیاں

تقسیم شدہ یک سنگی نظام۔ سروسز جنہیں ایک ساتھ تعینات کرنا ہو اور جو ڈیٹا بیس بانٹتی ہوں: تقسیم کی ساری لاگت، آزادی کی کوئی نہیں۔
نینو سروسز۔ سروسز اتنی باریک کہ آرکسٹریشن اور نیٹ ورک کا اضافی بوجھ ان کے کام سے بڑھ جائے۔
پلیٹ فارم کے بغیر مائیکرو سروسز۔ CI/CD، ٹریسنگ، اور آن کال کی پختگی سے پہلے تقسیم؛ ناکامی کے طریقے بڑھتے ہیں۔
ہستی سروسز۔ کاروباری صلاحیت کی بجائے ڈیٹا بیس ٹیبل کے حساب سے تقسیم (“صارف کی سروس”، “آرڈر کی سروس”)، ہر عمل کے لیے بکواسی سروسز کے پار کالز مجبور کرتی ہے۔
ہر جگہ ایونٹ سورسنگ۔ ان ڈومینز پر لاگو کرنا جنہیں آڈٹ کا نشان نہیں چاہیے، فائدے کے بغیر پیچیدگی کا محصول ادا کرنا۔
یک سنگی نظام کے طور پر گیٹ وے۔ API گیٹ وے میں کاروباری منطق رکھنا، مرکزی تنگ نقطہ دوبارہ بنانا۔
فریم ورک سے جڑا مرکز۔ ویب یا ORM (object-relational mapping) فریم ورک سے الجھی کاروباری منطق، جو ٹیسٹنگ اور ٹیکنالوجی کی تبدیلی دونوں تکلیف دہ بناتی ہے۔

پختگی کا ماڈل

سطح 1: آغاز۔ اسلوب فیشن یا اتفاق سے چنا جاتا ہے۔ آپ کے پاس ایک الجھا یک سنگی نظام یا اتفاقی تقسیم شدہ گڑبڑ ہے، حدیں ڈومین کی بجائے تکنیکی تہوں یا تاریخ کی پیروی کرتی ہیں، اور تقسیمیں تب ردعملی طور پر ہوتی ہیں جب کچھ ٹوٹتا ہے۔
سطح 2: ترقی۔ کچھ ٹیمیں یک سنگی نظام کے اندر جان بوجھ کر ماڈیول کی حدیں کھینچتی ہیں یا چند موٹی سروسز کھڑی کرتی ہیں، اور کچھ ہمہ گیر معاملات مستقل طور پر سنبھلتے ہیں۔ عمل ناہموار ہے: ایک گروہ سروسز کو محدود سیاق سے ہم آہنگ کرتا ہے جبکہ دوسرا اب بھی ڈیٹا بیس ٹیبل کے حساب سے تقسیم کرتا ہے، اور اخراج فی البدیہہ رہتا ہے۔
سطح 3: معیار بندی۔ دستاویزی طریقہ پورے ادارے میں نافذ ہے: سروسز محدود سیاق سے ہم آہنگ ہیں اور اپنے ڈیٹا کی مالک ہیں، گیٹ وے اور BFF کے نمونے مناسب جگہ استعمال ہوتے ہیں، اندرونی صاف یا ہیکساگونل تہہ بندی معیار ہے، اور ہر تقسیم کو بیان شدہ محرک چاہیے۔ ماڈیول کی حدیں محض رواج کی بجائے ٹولنگ سے نافذ ہیں۔
سطح 4: انتظام۔ اسلوب کے فیصلے بنیادی خطوط کے مقابل ناپے اور کنٹرول کیے جاتے ہیں۔ آپ فی سروس تعیناتی کی تعدد اور لیڈ ٹائم، بحالی کا اوسط وقت، عام تبدیلی کے لیے کتنی سروسز کو ایک ساتھ تعینات کرنا پڑتا ہے، اور نیٹ ورک ہاپ کی لیٹنسی ٹریک کرتے ہیں، اور ہر تقسیم کی لاگت کا موازنہ اس آزادی سے کرتے ہیں جو اسے خریدنی تھی۔ حد کے باقی رہنے کا فیصلہ ترجیح کی بجائے شہادت کرتی ہے، اور تقسیم شدہ یک سنگی نظام کی طرف بھٹکاؤ بندش کی بجائے اشاریوں سے پکڑا جاتا ہے۔
سطح 5: ہم آہنگی۔ فن تعمیر تنظیمی ڈیزائن سے مربوط ہے اور مسلسل ڈھلتا ہے۔ پختہ پلیٹ فارم (CI/CD، ٹریسنگ، اور جہاں جائز ہو میش) تقسیم اور دوبارہ یکجا کرنا دونوں سستے بناتا ہے، ٹیمیں معمول سے محرک ظاہر ہونے پر نکالتی ہیں اور غائب ہونے پر سروسز کو واپس تہہ کرتی ہیں، اور اسلوب کے انتخاب ٹیم کی ٹوپولوجی، بوجھ، اور خطرے کی تصویر بدلنے کے ساتھ پوری جائیداد میں دوبارہ متوازن ہوتے ہیں۔

بحث کے لیے خیالات

آپ کے نظام میں یک سنگی نظام کہاں دراصل طاقت ہے، اور کہاں حقیقی رکاوٹ؟
کون سا ٹھوس محرک آپ کی اگلی سروس نکالنے کا جواز دے گا، اور کیا آپ اسے بنانے سے پہلے اس کا نام لے سکتے ہیں؟
کیا آپ کے ادارے کے پاس وہ آپریشنل پختگی ہے جو مائیکرو سروسز مانگتی ہیں؟ کیا غائب ہے؟
آپ کے ڈومین کے کن حصوں کے لیے مکمل ایونٹ سورس آڈٹ کا نشان قانونی یا کاروباری ضرورت ہے بمقابلہ اچھا ہونا؟
آپ کی موجودہ سروس کی حدیں آپ کی ٹیم کی حدوں کی کتنی اچھی عکاسی کرتی ہیں، اور کیا وہ ہم آہنگی مدد کر رہی ہے یا نقصان؟
اگر آپ کو اگلے سال اپنا ویب فریم ورک یا ڈیٹا بیس بدلنا پڑے تو آپ کی کاروباری منطق کا کتنا حصہ دوبارہ لکھنا پڑے گا؟

اہم نکات

فن تعمیر کا اسلوب حقیقی قوتوں (ٹیم کا سائز، ڈومین، بوجھ، آپریشنل پختگی) سے چنیں، فیشن سے نہیں۔
ماڈیولر یک سنگی نظام زیادہ تر نظاموں کے لیے درست ڈیفالٹ ہے؛ سروسز صرف ٹھوس محرک کے ساتھ اور محدود سیاق کی لکیروں پر نکالیں۔
مائیکرو سروسز آزادانہ تعیناتی، پیمائش، اور ناکامی کی تنہائی کے بدلے آپریشنل اور ذہنی پیچیدگی لیتی ہیں؛ انہیں پختہ پلیٹ فارم چاہیے۔
ایونٹ پر مبنی، CQRS، اور ایونٹ سورسنگ حتمی مطابقت اور ورژننگ کی پیچیدگی کی قیمت پر ڈھیلا جوڑ اور آڈٹ کی اہلیت دیتے ہیں؛ جان بوجھ کر اپنائیں۔
گیٹ ویز، BFFs، اور میشز بہت سی سروسز کی جائیدادوں کو سدھارتے ہیں مگر وزن جوڑتے ہیں؛ انہیں تب متعارف کروائیں جب پیمانہ تقاضا کرے، اس سے پہلے نہیں۔
قیمتی کاروباری منطق کو ٹیکنالوجی کی تبدیلی کے پار قابل ٹیسٹ اور پائیدار رکھنے کے لیے ہر سروس کے اندر ہیکساگونل/صاف فن تعمیر لاگو کریں۔

حوالہ جات اور مزید مطالعہ

Sam Newman, Building Microservices and Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (and articles on CQRS and Event Sourcing)
Matthew Skelton and Manuel Pais, Team Topologies