AI च्या युगात डोमेन मॉडेल्स (Domain Models) अधिक महत्त्वाचे का आहेत

सॉफ्टवेअर आर्किटेक्चर (Software architecture) हा अनेकदा असा वाद असतो ज्याचा कोणताही विजेता नसतो. तुम्ही एक सिस्टम तयार करता. पण त्याच परिस्थितीत तुम्ही पर्यायी सिस्टम कधीच तयार करत नाही. यामुळे प्रत्येक निर्णय पडताळण्यास अशक्य (unfalsifiable) ठरतो. जेव्हा एखादी सिस्टम फेल होते, तेव्हा लोक डोमेनला किंवा टीमला दोष देतात. ते क्वचितच आर्किटेक्चरला दोष देतात कारण त्याची तुलना करण्यासाठी कोणताही 'कंट्रोल ग्रुप' (control group) उपलब्ध नसतो.

आपल्याला आपल्या डिझाइन्सची चाचणी घेण्यासाठी एका मार्गाची गरज आहे. आपण 'एसेन्शिअल कॉम्प्लेक्सिटी' (essential complexity) आणि 'ॲक्सिडेंटल कॉम्प्लेक्सिटी' (accidental complexity) वेगळी केली पाहिजे. एसेन्शिअल कॉम्प्लेक्सिटी म्हणजे प्रत्यक्ष समस्या आहे. ॲक्सिडेंटल कॉम्प्लेक्सिटी म्हणजे आपल्या टूल्स आणि प्रक्रियेमुळे आपण निर्माण केलेला गोंधळ आहे.

AI मुळे अंमलबजावणी (implementation) जवळजवळ मोफत झाली आहे. हा एक मोठा बदल आहे. पूर्वी, कोड लिहिण्यातील अडथळ्यांमुळे (friction) डेव्हलपर्सना अधिक चांगल्या स्ट्रक्चर्सची निर्मिती करण्यास भाग पाडले जात असे. जर तुमचा कोड विस्कळीत असेल, तर तो व्यवस्थापित करणे कठीण व्हायचे. तो त्रास एक 'फीडबॅक लूप' (feedback loop) म्हणून काम करायचा.

AI तो अडथळा दूर करते. ते स्वच्छ कोडप्रमाणेच विस्कळीत आणि खराब स्ट्रक्चर असलेला कोड देखील तितक्याच वेगाने लिहू शकते. खराब मॉडेलचा त्रास आता डेव्हलपरला बिल्ड (build) दरम्यान जाणवत नाही. त्याऐवजी, तो त्रास प्रोडक्शन (production) मध्ये जाणवतो. तुम्हाला भ्रष्ट डेटा (corrupt data) आणि अशक्य इंटिग्रेशन टास्कचा सामना करावा लागतो.

हे टाळण्यासाठी 'रिच डोमेन मॉडेल' (rich domain model) हे एक साधन आहे. ते तीन विशिष्ट कामे करते:

  • ते तुम्हाला संकल्पनांना (concepts) आकार देण्यास भाग पाडून डोमेन समजून घेण्यास मदत करते.
  • ते डोमेनची व्याख्या करते, ज्यामुळे "काय तयार करायचे" हा आता केवळ अंदाज राहत नाही.
  • ते कोडमध्ये डोमेनचे दस्तऐवजीकरण (document) करते, जे कंपायलरद्वारे (compiler) अपडेट राहते.

कार्यक्षमतेसाठी, डोमेन मॉडेलने तीन नियमांचे पालन केले पाहिजे:

  • एसेन्शिअल कॉम्प्लेक्सिटी अखंड ठेवा. एकाच संकल्पनेला शेकडो मायक्रोसर्व्हिसेसमध्ये (microservices) विखुरू नका.
  • फीडबॅक द्या. चुकीच्या गृहितकामुळे 'कॉम्पिल एरर' (compile error) येणे आवश्यक आहे, कोणताही 'सायलेंट बग' (silent bug) नाही.
  • बदल स्वस्त ठेवा. तुम्हाला एखादी संकल्पना एकाच ठिकाणी सुधारावी लागूली पाहिजे, दहा सर्व्हिसेसमध्ये ती शोधण्याची गरज पडू नये.

जर तुम्ही "ब्लोट" (bloat) कमी करण्यासाठी तुमचे डोमेन खूप लवकर मायक्रोसर्व्हिसेसमध्ये विभागले, तर तुम्ही अनेकदा फक्त तो गोंधळ दुसऱ्या ठिकाणी हलवता. तुम्ही एका "गॉड ऑब्जेक्ट"च्या (god object) बदल्यात एक विखुरलेला गोंधळ मिळवता जो ट्रॅक करणे अधिक कठीण असते. ज्या डिपेंडन्सी (dependency) तुम्हाला दिसत नाहीत, त्या प्रोडक्शनमध्ये बिघडण्याची शक्यता असते.

रिच डोमेन मॉडेलचे ध्येय नेहमी बरोबर असणे हे नाही. ध्येय हे आहे की, जेव्हा तुम्ही चुकीचे असता, तेव्हा सुधारण्याचा खर्च कमी असतानाच ती चूक स्पष्टपणे दिसून यावी.

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