𝗗𝗗𝗗 𝗜𝘀 𝗡𝗼𝘁 𝗗𝘆𝗶𝗻𝗴. 𝗖𝗮𝗿𝗴𝗼-𝗖𝘂𝗹𝘁 𝗗𝗗𝗗 𝗜𝘀.
Domain-Driven Design (DDD) मर नहीं रहा है।
AI के कारण अब DDD का मूल मूल्य (core value) और भी महत्वपूर्ण हो गया है। आपको अभी भी इनकी आवश्यकता है:
- जटिल बिजनेस डोमेन (business domains) को समझना
- bounded contexts को परिभाषित करना
- इंजीनियरों और विशेषज्ञों के बीच भाषा को संरेखित (align) करना
- invariants की खोज करना
- state transitions को स्पष्ट बनाना
AI कोड जनरेट करना सस्ता बना देता है। यह अस्पष्ट सोच को और भी खतरनाक बना देता है। यदि आपका डोमेन लॉजिक (domain logic) अव्यवस्थित है, तो AI केवल आपको और तेज़ी से अव्यवस्था फैलाने में मदद करेगा।
समस्या DDD नहीं है। समस्या cargo-cult DDD है।
कई टीमें समझ विकसित करने के बजाय नियंत्रण के उपकरण के रूप में tactical DDD का उपयोग करती हैं। वे पैटर्न का पालन केवल पालन करने के लिए करती हैं:
- एक Entity बनाना
- एक Repository जोड़ना
- एक Mapper लिखना
- डायरेक्टरी स्ट्रक्चर का पालन करना
ये पैटर्न बुरे नहीं हैं। लेकिन वे अक्सर आर्किटेक्चरल कागजी कार्रवाई (architectural paperwork) बनकर रह जाते हैं। यदि एक Repository केवल एक renamed DAO है, या एक Mapper बिना किसी अर्थ के केवल फ़ील्ड्स को स्थानांतरित करता है, तो आप डोमेन को मॉडल नहीं कर रहे हैं। आप केवल फॉर्म भर रहे हैं।
यह आर्किटेक्चर के रूप में व्यक्त की गई नौकरशाही (bureaucracy) है।
AI इस तरह के काम के लिए एकदम सही है। यह सेकंडों में mappers, DTOs, और boilerplate जनरेट कर सकता है।
यदि आप नौकरशाही को तेज़ करने के लिए AI का उपयोग करते हैं, तो आप केवल औपचारिकता (ceremony) को तेज़ करते हैं। आप देख सकते हैं कि अधिक टिकट्स आगे बढ़ रहे हैं, लेकिन आप बेहतर सिस्टम नहीं बना रहे हैं। आप केवल कचरे (waste) के उत्पादन को सस्ता बना रहे हैं।
असली प्रतिस्पर्धा दो प्रकार के संगठनों के बीच है:
बड़े AI-सहायता प्राप्त नौकरशाही वाले दल (Large AI-assisted bureaucratic teams) ये टीमें अधिक लेयर्स और अधिक boilerplate जनरेट करने के लिए AI का उपयोग करती हैं। वे मौजूदा पैटर्न का पालन करने और औपचारिक समीक्षाओं (formal reviews) को पास करने पर ध्यान केंद्रित करती हैं।
छोटे AI-संवर्धित उच्च-स्वामित्व वाले दल (Small AI-amplified high-ownership teams) ये टीमें सिस्टम को सुरक्षित रूप से बदलने की अपनी क्षमता बढ़ाने के लिए AI का उपयोग करती हैं। वे इन पर ध्यान केंद्रित करते हैं:
- निष्पादन योग्य विशिष्टताएँ (Executable specifications)
- मजबूत सीमाएँ (Strong boundaries)
- स्वचालित परीक्षण (Automated tests)
- टाइप-लेवल बाधाएं (Type-level constraints)
- स्पष्ट state transitions
पहला प्रकार अधिक औपचारिकता (ceremony) पैदा करने के लिए AI का उपयोग करता है। दूसरा प्रकार औपचारिकता की आवश्यकता को समाप्त करने के लिए AI का उपयोग करता है।
लोगों या कोड को नियंत्रित करने के लिए आर्किटेक्चर का उपयोग करना बंद करें। इसका उपयोग डोमेन के अर्थ की रक्षा करने के लिए करें।
मानव समीक्षा (human review) द्वारा संरक्षित आर्किटेक्चर से हटकर परीक्षणों (tests), प्रकारों (types), और बाधाओं (constraints) द्वारा संरक्षित आर्किटेक्चर की ओर बढ़ें।
Source: https://dev.to/terum/ddd-is-not-dying-cargo-cult-ddd-is-l1p
Optional learning community: https://t.me/GyaanSetuAi