𝗪𝗵𝘆 𝗗𝗼𝗺𝗮𝗶𝗻 𝗠𝗼𝗱𝗲𝗹𝘀 𝗠𝗮𝘁𝘁𝗲𝗿 𝗠𝗼𝗿𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗜 𝗘𝗿𝗮

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

ہمیں اپنے ڈیزائنز کو جانچنے کے لیے ایک طریقے کی ضرورت ہے۔ ہمیں 'essential complexity' (بنیادی پیچیدگی) کو 'accidental complexity' (اتفاقی پیچیدگی) سے الگ کرنا چاہیے۔ بنیادی پیچیدگی اصل مسئلہ ہے۔ اتفاقی پیچیدگی وہ گڑبڑ ہے جو ہم اپنے ٹولز اور عمل (processes) کے ذریعے پیدا کرتے ہیں۔

AI کے ذریعے عمل درآمد (implementation) تقریباً مفت ہو گیا ہے۔ یہ ایک بہت بڑی تبدیلی ہے۔ ماضی میں، کوڈ لکھنے کی دشواری ڈویلپرز کو بہتر ڈھانچے بنانے پر مجبور کرتی تھی۔ اگر آپ کا کوڈ بکھرا ہوا ہوتا، تو اسے سنبھالنا مشکل ہو جاتا تھا۔ وہ تکلیف ایک فیڈ بیک لوپ کا کام کرتی تھی۔

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

ایک rich domain model اس سے بچنے کا ایک ذریعہ ہے۔ یہ تین مخصوص کام انجام دیتا ہے:

  • یہ آپ کو تصورات (concepts) کو شکل دینے پر مجبور کر کے ڈومین سیکھنے میں مدد دیتا ہے۔
  • یہ ڈومین کی وضاحت کرتا ہے تاکہ "کیا بنانا ہے" اب کوئی اندازہ نہ رہے۔
  • یہ کوڈ کے ذریعے ڈومین کی دستاویز سازی (documentation) کرتا ہے جو کمپائلر کے ذریعے اپ ڈیٹ رہتی ہے۔

کام کرنے کے لیے، ایک ڈومین ماڈل کو تین اصولوں پر عمل کرنا چاہیے:

  • بنیادی پیچیدگی کو مکمل رکھیں۔ ایک ہی تصور (concept) کو سینکڑوں مائیکرو سروسز (microservices) میں نہ بکھیریں۔
  • فیڈ بیک فراہم کریں۔ ایک غلط مفروضہ 'compile error' کا باعث بننا چاہیے، نہ کہ کسی خاموش بگ (silent bug) کا۔
  • تبدیلیوں کو سستا رکھیں۔ آپ کو ایک تصور کو ایک ہی جگہ ٹھیک کرنا چاہیے، نہ کہ اسے دس سروسز میں تلاش کرنا پڑے۔

اگر آپ "bloat" (اضافی بوجھ) کو ختم کرنے کے لیے اپنے ڈومین کو بہت جلد مائیکرو سروسز میں تقسیم کر دیتے ہیں، تو اکثر آپ صرف گڑبڑ کو ایک جگہ سے دوسری جگہ منتقل کر رہے ہوتے ہیں۔ آپ ایک واحد "god object" کے بدلے ایک ایسی بکھری ہوئی گڑبڑ حاصل کر لیتے ہیں جسے ٹریک کرنا زیادہ مشکل ہوتا ہے۔ ایک ایسی وابستگی (dependency) جسے آپ دیکھ نہیں سکتے، وہی پروڈکشن میں ٹوٹ جائے گی۔

ایک rich domain model کا مقصد درست ہونا نہیں ہے۔ اس کا مقصد غلطی کو اس وقت نمایاں کرنا ہے جب اسے درست کرنے کی لاگت ابھی کم ہو۔

Source: https://dev.to/leonpennings/what-is-the-reason-for-using-a-rich-domain-model-in-the-age-of-ai-3gg

Optional learning community: https://t.me/GyaanSetuAi