𝗗𝗗𝗗 𝗜𝘀 𝗡𝗼𝘁 𝗗𝘆𝗶𝗻𝗴. 𝗖𝗮𝗿𝗴𝗼-𝗖𝘂𝗹𝘁 𝗗𝗗𝗗 𝗜𝘀.

Domain-Driven Design (DDD) মরছে না।

AI-এর কারণে DDD-এর মূল গুরুত্ব এখন আরও বেশি। আপনার এখনও প্রয়োজন:

  • জটিল বিজনেস ডোমেইন বোঝা
  • bounded contexts সংজ্ঞায়িত করা
  • ইঞ্জিনিয়ার এবং বিশেষজ্ঞদের মধ্যে ভাষার সামঞ্জস্য বজায় রাখা
  • invariants খুঁজে বের করা
  • state transitions-কে স্পষ্ট করা

AI কোড জেনারেট করা সহজ ও সস্তা করে তুলেছে। এটি অস্পষ্ট চিন্তাভাবনাকে আরও বিপজ্জনক করে তোলে। আপনার ডোমেইন লজিক যদি অগোছালো হয়, তবে AI কেবল সেই অগোছালো অবস্থা আরও দ্রুত তৈরি করতে আপনাকে সাহায্য করবে।

সমস্যাটি DDD-এ নয়। সমস্যাটি হলো কার্গো-কাল্ট (cargo-cult) DDD-এ।

অনেক টিম বোঝার চেয়ে নিয়ন্ত্রণের হাতিয়ার হিসেবে tactical DDD ব্যবহার করে। তারা কেবল নিয়ম মেনে চলার জন্য প্যাটার্ন অনুসরণ করে:

  • একটি Entity তৈরি করা
  • একটি Repository যোগ করা
  • একটি Mapper লেখা
  • ডিরেক্টরি স্ট্রাকচার অনুসরণ করা

এই প্যাটার্নগুলো খারাপ নয়। কিন্তু এগুলো প্রায়ই আর্কিটেকচারাল পেপারওয়ার্কে (paperwork) পরিণত হয়। যদি একটি Repository কেবল একটি রিনেম করা DAO হয়, অথবা একটি Mapper কোনো অর্থ ছাড়াই কেবল ফিল্ডগুলো মুভ করে, তবে আপনি কোনো ডোমেইন মডেল করছেন না। আপনি কেবল ফর্ম পূরণ করছেন।

এটি হলো আর্কিটেকচারের ছদ্মবেশে আমলাতন্ত্র।

এই ধরণের কাজের জন্য AI একদম নিখুঁত। এটি কয়েক সেকেন্ডের মধ্যে mappers, DTOs এবং boilerplate তৈরি করতে পারে।

আপনি যদি আমলাতন্ত্রকে ত্বরান্বিত করতে AI ব্যবহার করেন, তবে আপনি কেবল আনুষ্ঠানিকতা (ceremony) বাড়িয়ে দিচ্ছেন। আপনি হয়তো দেখবেন আরও বেশি টিকিট মুভ করছে, কিন্তু আপনি উন্নত সিস্টেম তৈরি করছেন না। আপনি কেবল অপচয় উৎপাদন করাকে আরও সস্তা করছেন।

আসল প্রতিযোগিতা হলো দুই ধরণের প্রতিষ্ঠানের মধ্যে:

  1. বড় AI-সহায়তা প্রাপ্ত আমলাতান্ত্রিক টিম এই টিমগুলো আরও বেশি লেয়ার এবং আরও বেশি boilerplate তৈরি করতে AI ব্যবহার করে। তারা বিদ্যমান প্যাটার্ন অনুসরণ করা এবং ফরমাল রিভিউ পাস করার দিকে মনোযোগ দেয়।

  2. ছোট AI-বর্ধিত উচ্চ-মালিকানা সম্পন্ন (high-ownership) টিম এই টিমগুলো সিস্টেমকে নিরাপদে পরিবর্তন করার ক্ষমতা বাড়াতে AI ব্যবহার করে। তারা নিচের বিষয়গুলোতে মনোযোগ দেয়:

  • Executable specifications
  • শক্তিশালী বাউন্ডারি (strong boundaries)
  • অটোমেটেড টেস্ট (automated tests)
  • Type-level constraints
  • স্পষ্ট state transitions

প্রথম ধরণের টিমগুলো আরও বেশি আনুষ্ঠানিকতা (ceremony) তৈরি করতে AI ব্যবহার করে। দ্বিতীয় ধরণের টিমগুলো আনুষ্ঠানিকতার প্রয়োজনীয়তা দূর করতে AI ব্যবহার করে।

মানুষ বা কোড নিয়ন্ত্রণ করার জন্য আর্কিটেকচার ব্যবহার করা বন্ধ করুন। ডোমেইনের অর্থ রক্ষা করার জন্য এটি ব্যবহার করুন।

মানুষের রিভিউ দ্বারা সুরক্ষিত আর্কিটেকচার থেকে সরে এসে টেস্ট, টাইপ এবং কনস্ট্রেইন্ট (constraints) দ্বারা সুরক্ষিত আর্কিটেকচারের দিকে এগিয়ে যান।

Source: https://dev.to/terum/ddd-is-not-dying-cargo-cult-ddd-is-l1p

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