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

সফটওয়্যার আর্কিটেকচার প্রায়শই এমন একটি বিতর্ক যেখানে কোনো বিজয়ী থাকে না। আপনি একটি সিস্টেম তৈরি করেন। একই পরিস্থিতিতে আপনি কখনোই এর বিকল্পটি তৈরি করেন না। এটি প্রতিটি সিদ্ধান্তকে অকাট্য (unfalsifiable) করে তোলে। যখন একটি সিস্টেম ব্যর্থ হয়, মানুষ ডোমেইন বা টিমের ওপর দোষ চাপায়। তারা খুব কমই আর্কিটেকচারের ওপর দোষারোপ করে, কারণ এর সাথে তুলনা করার মতো কোনো কন্ট্রোল গ্রুপ থাকে না।

আমাদের ডিজাইনগুলো পরীক্ষা করার জন্য একটি উপায়ের প্রয়োজন। আমাদের essential complexity (অপরিহার্য জটিলতা) থেকে accidental complexity (আকস্মিক জটিলতা) আলাদা করতে হবে। Essential complexity হলো প্রকৃত সমস্যা। Accidental complexity হলো আমাদের টুলস এবং প্রসেস দিয়ে তৈরি করা বিশৃঙ্খলা।

AI ইমপ্লিমেন্টেশন বা বাস্তবায়নকে প্রায় বিনামূল্যে বা অত্যন্ত সহজ করে তুলেছে। এটি একটি বিশাল পরিবর্তন। অতীতে, কোড লেখার শ্রম বা ঘর্ষণ ডেভেলপারদের আরও উন্নত কাঠামো তৈরি করতে বাধ্য করত। যদি আপনার কোড বিশৃঙ্খল হতো, তবে তা পরিচালনা করা কঠিন হয়ে পড়ত। সেই কষ্টটি ছিল একটি ফিডব্যাক লুপ।

AI সেই বাধা বা ঘর্ষণ দূর করে দেয়। এটি পরিষ্কার কোডের মতোই দ্রুত বিশৃঙ্খল এবং দুর্বলভাবে গঠিত কোড লিখতে পারে। একটি খারাপ মডেলের কষ্ট এখন আর বিল্ড করার সময় ডেভেলপারের কাছে পৌঁছায় না। পরিবর্তে, সেই কষ্টটি প্রোডাকশনে চলে যায়। আপনি তখন ডেটা করাপশন এবং অসম্ভব ইন্টিগ্রেশন টাস্কের সম্মুখীন হন।

একটি rich domain model এটি প্রতিরোধ করার একটি হাতিয়ার। এটি তিনটি নির্দিষ্ট কাজ করে:

  • এটি আপনাকে কনসেপ্টগুলোকে একটি নির্দিষ্ট রূপ দিতে বাধ্য করার মাধ্যমে ডোমেইন শিখতে সাহায্য করে।
  • এটি ডোমেইনকে সংজ্ঞায়িত করে যাতে "কী তৈরি করতে হবে" তা আর অনুমানের ওপর নির্ভর না থাকে।
  • এটি কোডের মাধ্যমে ডোমেইনকে ডকুমেন্ট করে যা কম্পাইলারের মাধ্যমে আপডেট থাকে।

কার্যকর হওয়ার জন্য, একটি ডোমেইন মডেলকে তিনটি নিয়ম মেনে চলতে হবে:

  • Essential complexity-কে অখণ্ড রাখুন। একটি মাত্র কনসেপ্টকে শত শত microservices-এর মধ্যে ছড়িয়ে দেবেন না।
  • ফিডব্যাক প্রদান করুন। একটি ভুল ধারণা বা অনুমান যেন একটি compile error তৈরি করে, কোনো silent bug নয়।
  • পরিবর্তন সহজ রাখুন। আপনার একটি কনসেপ্ট এক জায়গায় ঠিক করা উচিত, দশটি সার্ভিসে সেটি খুঁজতে হওয়া উচিত নয়।

আপনি যদি "bloat" বা অতিরিক্ত ভার কমানোর জন্য খুব দ্রুত আপনার ডোমেইনকে microservices-এ ভাগ করে ফেলেন, তবে আপনি প্রায়শই কেবল বিশৃঙ্খলাটিকে এক জায়গা থেকে অন্য জায়গায় স্থানান্তর করেন। আপনি একটি একক "god object"-এর বদলে একটি distributed mess-এর সম্মুখীন হন যা ট্র্যাক করা আরও কঠিন। আপনি যে 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