AI யுகத்தில் டொமைன் மாடல்கள் ஏன் மிக முக்கியமானவை

மென்பொருள் கட்டமைப்பு (Software architecture) என்பது பெரும்பாலும் வெற்றியற்ற ஒரு விவாதமாகவே இருக்கிறது. நீங்கள் ஒரு அமைப்பை உருவாக்குகிறீர்கள். அதே சூழ்நிலையில் மாற்று அமைப்பை நீங்கள் ஒருபோதும் உருவாக்குவதில்லை. இது ஒவ்வொரு முடிவையும் நிரூபிக்க முடியாததாக மாற்றுகிறது. ஒரு அமைப்பு தோல்வியடையும் போது, மக்கள் டொமைன் அல்லது குழுவை blame செய்கிறார்கள். ஒப்பிடுவதற்கு ஒரு கட்டுப்பாட்டு குழு (control group) இல்லாததால், அவர்கள் அரிதாகவே கட்டமைப்பை (architecture) குற்றம் சாட்டுகிறார்கள்.

எங்கள் வடிவமைப்புகளைச் சோதிக்க நமக்கு ஒரு வழி தேவை. அத்தியாவசிய சிக்கலையும் (essential complexity) தற்செயலான சிக்கலையும் (accidental complexity) நாம் பிரிக்க வேண்டும். அத்தியாவசிய சிக்கல் என்பது உண்மையான பிரச்சனை. தற்செயலான சிக்கல் என்பது நமது கருவிகள் மற்றும் செயல்முறைகளால் நாம் உருவாக்கும் குழப்பமாகும்.

AI, செயலாக்கத்தை (implementation) கிட்டத்தட்ட இலவசமாக்குகிறது. இது ஒரு மிகப்பெரிய மாற்றம். கடந்த காலத்தில், குறியீடு (code) எழுதுவதில் இருந்த சிரமம், டெவலப்பர்களை சிறந்த கட்டமைப்புகளை உருவாக்கத் தூண்டியது. உங்கள் குறியீடு குழப்பமாக இருந்தால், அதை நிர்வகிப்பது கடினமாக இருந்தது. அந்த வலி ஒரு பின்னூட்டச் சுழற்சியாக (feedback loop) இருந்தது.

AI அந்த சிரமத்தை நீக்குகிறது. சுத்தமான குறியீட்டைப் போலவே, ஒழுங்கற்ற மற்றும் மோசமான கட்டமைப்பைக் கொண்ட குறியீட்டையும் அது மிக வேகமாக எழுத முடியும். ஒரு மோசமான மாடலின் வலி, உருவாக்கத்தின் (build) போது டெவலப்பரைத் தாக்குவதில்லை. மாறாக, அந்த வலி தயாரிப்பு சூழலுக்கு (production) மாறுகிறது. நீங்கள் சிதைந்த தரவுகளையும் (corrupt data), சாத்தியமற்ற ஒருங்கிணைப்புப் பணிகளையும் எதிர்கொள்ள நேரிடும்.

இதைத் தடுப்பதற்கான ஒரு கருவியாக ஒரு செழுமையான டொமைன் மாடல் (rich domain model) செயல்படுகிறது. இது மூன்று குறிப்பிட்ட பணிகளைச் செய்கிறது:

  • கருத்துகளுக்கு வடிவம் கொடுக்கக் கட்டாயப்படுத்துவதன் மூலம், டொமைனை நீங்கள் கற்றுக்கொள்ள உதவுகிறது.
  • டொமைனை வரையறுப்பதன் மூலம் "என்ன உருவாக்குவது" என்பது இனி ஒரு யூகமாக இருக்காது.
  • கம்பைலர் (compiler) மூலம் புதுப்பிக்கப்பட்ட நிலையில் இருக்கும் குறியீட்டின் மூலம் டொமைனை ஆவணப்படுத்துகிறது.

செயல்பட, ஒரு டொமைன் மாடல் மூன்று விதிகளைப் பின்பற்ற வேண்டும்:

  • அத்தியாவசிய சிக்கலை முழுமையாக வைத்திருக்கவும். ஒரே ஒரு கருத்தை நூற்றுக்கணக்கான மைக்ரோசர்வீஸ்கள் (microservices) முழுவதும் சிதறடிக்க வேண்டாம்.
  • பின்னூட்டத்தை வழங்க வேண்டும். ஒரு தவறான அனுமானம் அமைதியான பிழையை (silent bug) ஏற்படுத்தாமல், கம்பைல் பிழையை (compile error) ஏற்படுத்த வேண்டும்.
  • மாற்றங்களை மலிவாக வைத்திருக்க வேண்டும். நீங்கள் ஒரு கருத்தை ஒரே இடத்தில் சரிசெய்ய வேண்டும், பத்து சேவைகளில் அதைத் தேட வேண்டிய அவசியமில்லை.

"வீக்கம்" (bloat) என்பதைத் தவிர்க்க உங்கள் டொமைனை மிக விரைவாக மைக்ரோசர்வீஸ்களாகப் பிரித்தால், நீங்கள் பெரும்பாலும் குழப்பத்தை இடமாற்றம் செய்கிறீர்கள் என்றுதான் அர்த்தம். நீங்கள் ஒரு தனிப்பட்ட "காட் ஆப்ஜெக்ட்டிற்கு" (god object) பதிலாக, கண்காணிக்க கடினமான ஒரு பரவலாக்கப்பட்ட குழப்பத்தை (distributed mess) மாற்றிக் கொள்கிறீர்கள். நீங்கள் பார்க்க முடியாத ஒரு சார்புநிலை (dependency), தயாரிப்பு சூழலில் (production) உடைந்து போகும் ஒரு சார்புநிலையாகும்.

ஒரு செழுமையான டொமைன் மாடலின் நோக்கம் சரியாக இருப்பது மட்டுமல்ல. திருத்தச் செலவு குறைவாக இருக்கும்போதே, தவறு செய்வதை வெளிப்படையாக்குவதே அதன் நோக்கமாகும்.

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