Architecture Decision RecordAWS میں آرکیٹیکچر فیصلے کے ریکارڈز کا عمل
آرکیٹیکچر فیصلے کا ریکارڈ (ADR) ایک دستاویز ہے جو اس سافٹ ویئر آرکیٹیکچر کے کسی اہم پہلو کے بارے میں ٹیم کے کیے گئے انتخاب کو بیان کرتی ہے جسے وہ بنانے کا منصوبہ بنا رہی ہے۔ ہر ADR آرکیٹیکچر کے فیصلے، اس کے سیاق و سباق اور اس کے نتائج کو بیان کرتا ہے۔ ADR کی مختلف حالتیں ہوتی ہیں، اس لیے وہ ایک زندگی کے چکر (lifecycle) پر چلتے ہیں۔ ADR کی مثال کے لیے ضمیمہ دیکھیں۔
ADR کے عمل کا نتیجہ آرکیٹیکچر فیصلے کے ریکارڈز کا ایک مجموعہ ہوتا ہے۔ یہ مجموعہ فیصلوں کا لاگ بناتا ہے۔ فیصلوں کا لاگ منصوبے کا سیاق و سباق اور عمل درآمد اور ڈیزائن کی تفصیلی معلومات فراہم کرتا ہے۔ منصوبے کے اراکین منصوبے کے سیاق و سباق کا عمومی جائزہ حاصل کرنے کے لیے ہر ADR کی سرخیاں دیکھ لیتے ہیں۔ وہ منصوبے کے عمل درآمد اور ڈیزائن کے انتخابات میں گہرائی میں جانے کے لیے ADR پڑھتے ہیں۔
جب ٹیم کوئی ADR قبول کر لیتی ہے تو وہ ناقابلِ تغیر (immutable) ہو جاتا ہے۔ اگر نئی بصیرت کسی مختلف فیصلے کی متقاضی ہو تو ٹیم نیا ADR تجویز کرتی ہے۔ جب ٹیم نیا ADR قبول کر لیتی ہے تو وہ پچھلے ADR کی جگہ لے لیتا ہے۔
ADR کے عمل کا دائرہ
منصوبے کے اراکین کو سافٹ ویئر منصوبے یا پروڈکٹ کو متاثر کرنے والے ہر آرکیٹیکچر کے لحاظ سے اہم فیصلے کے لیے ایک ADR بنانا چاہیے، جن میں درج ذیل شامل ہیں (Richards and Ford 2020):
ڈھانچہ (مثلاً مائیکرو سروسز جیسے پیٹرنز)
غیر فعلی تقاضے (سیکیورٹی، اعلیٰ دستیابی اور خرابی برداشت)
انحصارات (اجزا کا باہمی جوڑ)
انٹرفیسز (APIs اور شائع شدہ معاہدے)
تعمیر کی تکنیکیں (لائبریریاں، فریم ورکس، ٹولز اور عمل)
فعلی اور غیر فعلی تقاضے ADR کے عمل کے سب سے عام ان پٹس ہیں۔
ADR کا مواد
جب ٹیم ADR کی ضرورت کی نشاندہی کرتی ہے تو ٹیم کا ایک رکن پورے منصوبے کے لیے مشترکہ سانچے کی بنیاد پر ADR لکھنا شروع کرتا ہے۔ (مثالی سانچوں کے لیے GitHub پر ADR تنظیم دیکھیں۔) سانچہ ADR کی تخلیق کو آسان بناتا ہے اور یقینی بناتا ہے کہ ADR تمام متعلقہ معلومات سمیٹ لے۔ کم از کم ہر ADR کو فیصلے کا سیاق و سباق، خود فیصلہ، اور منصوبے اور اس کے ڈیلیورایبلز کے لیے فیصلے کے نتائج متعین کرنے چاہئیں۔ (ان حصوں کی مثالوں کے لیے ضمیمہ دیکھیں۔) ADR کے ڈھانچے کے سب سے طاقتور پہلوؤں میں سے ایک یہ ہے کہ وہ اس بات پر توجہ دیتا ہے کہ فیصلہ کیوں کیا گیا، نہ کہ ٹیم نے اسے کیسے نافذ کیا۔ یہ سمجھنا کہ ٹیم نے فیصلہ کیوں کیا، دوسرے ٹیم اراکین کے لیے اسے اپنانا آسان بناتا ہے، اور ان دوسرے آرکیٹیکٹس کو جو فیصلہ سازی کے عمل میں شامل نہیں تھے، مستقبل میں اس فیصلے کو رد کرنے سے روکتا ہے۔
ADR کو اپنانے کا عمل
ہر ٹیم رکن ADR بنا سکتا ہے، لیکن ٹیم کو ADR کی ملکیت کی تعریف طے کرنی چاہیے۔ ہر مصنف جو کسی ADR کا مالک ہے، اسے ADR کے مواد کو فعال طور پر برقرار رکھنا اور اس کی ترسیل کرنی چاہیے۔ اس ملکیت کو واضح کرنے کے لیے یہ گائیڈ آنے والے حصوں میں ADR کے مصنفین کو ADR کے مالکان کہتی ہے۔ دوسرے ٹیم اراکین ہمیشہ ADR میں حصہ ڈال سکتے ہیں۔ اگر ٹیم کے ADR قبول کرنے سے پہلے اس کا مواد بدل جائے تو مالک کو ان تبدیلیوں کی منظوری دینی چاہیے۔
جب ٹیم آرکیٹیکچر کے فیصلے اور اس کے مالک کی نشاندہی کر لیتی ہے تو ADR کا مالک عمل کے آغاز میں ADR کو Proposed (تجویز شدہ) حالت میں پیش کرتا ہے۔ Proposed حالت کے ADR جائزے کے لیے تیار ہیں۔
اس کے بعد ADR کا مالک ADR کے جائزے کا عمل شروع کرتا ہے۔ ADR کے جائزے کے عمل کا مقصد یہ فیصلہ کرنا ہے کہ ٹیم ADR کو قبول کرتی ہے، یہ طے کرتی ہے کہ اس پر دوبارہ کام کی ضرورت ہے، یا اسے رد کرتی ہے۔ مالک سمیت منصوبے کی ٹیم ADR کا جائزہ لیتی ہے۔ جائزے کی میٹنگ کا آغاز ADR پڑھنے کے لیے مخصوص وقت سے ہونا چاہیے۔ اوسطاً 10 سے 15 منٹ کافی ہونے چاہئیں۔ اس دوران ہر ٹیم رکن دستاویز پڑھتا ہے اور غیر واضح موضوعات کی نشاندہی کے لیے تبصرے اور سوالات شامل کرتا ہے۔ جائزے کے مرحلے کے بعد ADR کا مالک ہر تبصرہ پڑھ کر سناتا ہے اور ٹیم کے ساتھ اس پر بات کرتا ہے۔
اگر ٹیم کو ADR کو بہتر بنانے کے لیے عملی نکات ملیں تو ADR کی حالت Proposed ہی رہتی ہے۔ ADR کا مالک اقدامات مرتب کرتا ہے اور ٹیم کے تعاون سے ہر اقدام کے لیے ایک ذمہ دار مقرر کرتا ہے۔ ہر ٹیم رکن عملی نکات میں حصہ ڈال سکتا اور انہیں حل کر سکتا ہے۔ جائزے کے عمل کا دوبارہ شیڈول طے کرنا ADR کے مالک کی ذمہ داری ہے۔
ٹیم ADR کو رد کرنے کا فیصلہ بھی کر سکتی ہے۔ اس صورت میں ADR کا مالک مستقبل میں اسی موضوع پر بحث سے بچنے کے لیے رد کرنے کی وجہ شامل کرتا ہے۔ مالک ADR کی حالت کو Rejected (مسترد) کر دیتا ہے۔
اگر ٹیم ADR کی منظوری دیتی ہے تو مالک ٹائم اسٹیمپ، ورژن اور اسٹیک ہولڈرز کی فہرست شامل کرتا ہے۔ پھر مالک حالت کو Accepted (قبول شدہ) کر دیتا ہے۔
ADR اور ان سے بننے والا فیصلوں کا لاگ ٹیم کے کیے گئے فیصلوں کی نمائندگی کرتے ہیں اور تمام فیصلوں کی تاریخ فراہم کرتے ہیں۔ جہاں ممکن ہو، ٹیم کوڈ اور آرکیٹیکچر کے جائزوں کے دوران ADR کو حوالے کے طور پر استعمال کرتی ہے۔ کوڈ کے جائزے، ڈیزائن کے کاموں اور عمل درآمد کے کاموں کے علاوہ، ٹیم اراکین کو پروڈکٹ کے حکمتِ عملی کے فیصلوں کے لیے ADR سے رجوع کرنا چاہیے۔
ایک اچھے طریقے کے طور پر، ہر سافٹ ویئر تبدیلی ہم مرتبہ جائزے (peer review) سے گزرے اور کم از کم ایک منظوری درکار ہو۔ کوڈ کے جائزے کے دوران جائزہ لینے والا ایسی تبدیلیاں پا سکتا ہے جو ایک یا زیادہ ADR کی خلاف ورزی کرتی ہیں۔ اس صورت میں جائزہ لینے والا کوڈ کی تبدیلی کے مصنف سے کوڈ اپ ڈیٹ کرنے کو کہتا ہے اور ADR کا لنک شیئر کرتا ہے۔ جب مصنف کوڈ اپ ڈیٹ کر دیتا ہے تو ہم مرتبہ جائزہ لینے والے اسے منظور کرتے ہیں اور وہ مرکزی کوڈ بیس میں ضم کر دیا جاتا ہے۔
ADR کے جائزے کا عمل
ٹیم کو ADR کو قبول یا رد کرنے کے بعد انہیں ناقابلِ تغیر دستاویزات سمجھنا چاہیے۔ موجودہ ADR میں تبدیلی کے لیے نیا ADR بنانا، نئے ADR کے لیے جائزے کا عمل قائم کرنا اور ADR کی منظوری دینا ضروری ہے۔ اگر ٹیم نئے ADR کی منظوری دیتی ہے تو مالک کو پرانے ADR کی حالت Superseded (منسوخ شدہ/تبدیل شدہ) کر دینی چاہیے۔