मैं डोमेन संचालित विकास पर कुछ पढ़ रहा हूं लेकिन यह नहीं देख सकता कि यह वास्तव में किसी भी विकास प्रथाओं को कैसे बदल सकता है, इसके अलावा हमारे डोमेन ऑब्जेक्ट नामों को हमारे आवश्यक दस्तावेज़ों में तत्वों के साथ insync रखना।डीडीडी के बारे में पढ़ने के बाद अब आप किस अभ्यास का उपयोग कर रहे हैं?
वास्तव में DDD में उन लोगों के लिए, यह कैसे अपने विकास pracitces बदल गया है?
बात मैं DDD के बारे में पता चला है कि यह महज अवधारणाओं और सिद्धांतों मैं पहले से ही इस्तेमाल किया नाम देता है। उपयोगी होने के लिए इसे सिस्टम विकसित करने के तरीके को बदलने की जरूरत नहीं है, यह केवल हमारे दृष्टिकोण पर चर्चा करने के लिए शब्दावली प्रदान कर सकता है।
कुछ चीजें हैं जो पढ़ने डोमेन प्रेरित डिजाइन जल्दी के बाद मेरे लिए बदल रहे हैं:
मैं अब aggregare जड़ें, संस्थाओं और मूल्य प्रकारों की पहचान।
मैं दृढ़ता परत को लागू करने के लिए nHibernate के साथ भंडार पैटर्न को अपनाया है।
(इसका कारण यह है इस ORM जब कुल सीमाओं को लागू करने में मेरे लिए एक अच्छा फिट की तरह लगता है है) मैं एक सर्वव्यापी भाषा का प्रयोग को गले लगाने के लिए, आप (शायद सबसे महत्वपूर्ण परिवर्तन मैं योगदान दिया) टलना।
उसके अलावा, DDD केवल औपचारिक रूप दिया गया है कि मैं क्या के रूप में सामान्य ज्ञान के बारे में सोचा।
यदि आप इसे पहले से नहीं देख चुके हैं तो यह आपकी रूचि रख सकता है- http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx – RichardOD
@ रिचर्डोड - इसके लिए धन्यवाद । विचार के लिए भोजन निश्चित रूप से ... – danielfishr
+1 मैं आपके उत्तर के साथ अधिक सहमत नहीं हो सका। मैं नेट के साथ काम नहीं कर रहा हूं लेकिन बाकी सब कुछ लागू होता है। डीडीडी को प्रभावी ढंग से लागू करने के लिए आपको प्रत्येक विषय पर चर्चा होने पर अपने अनुभव को पहचानना होगा, और इवान की पुस्तक उन वास्तविक विषयों के बारे में पुनर्विचार करने के लिए एक मूल्यवान टूल है जो आप पहले से ही वास्तविक परियोजनाओं में सामना कर रहे हैं। – JuanZe
नहीं काफी अपने प्रश्न का उत्तर है, लेकिन ...
आप एक प्रमुख मुद्दा भुला दिया है: एक व्यक्ति/टीम आपकी आवश्यकता दस्तावेज़ों के लिए सामग्री का निर्माण किया। लेकिन वे उस दस्तावेज़ में निष्कर्षों पर कैसे पहुंचे? क्या वे समस्याएं पेश कर रहे हैं, या समस्या स्थान के उनकी समझ हैं। क्या यह संभव है कि दस्तावेज़ के कुछ हिस्सों गलत हैं? या दस्तावेज़ के निर्माण के बाद से आवश्यकताएं बदल गई हैं?
तथ्य यह है कि, डीडीडी में से पहले कोड लिखना शुरू कर देता है। एरिक इवांस यह सुझाव नहीं दे रहे थे कि डीडीडी कोड लिखने का एक ठोस तरीका है; DDD व्यापार समस्या की पहचान, और इसमें शामिल लोगों को स्पष्टता लाने के लिए एक ठोस तरीका है। कार्यान्वयन हिस्सा माध्यमिक है।
आप एक स्थान जहाँ किसी और सटीक आवश्यकताओं बनाता है में हैं, और आप एक समाधान है, तो महान ऊपर कोड है। लेकिन यदि आप ऐसी स्थिति में हैं जहां आप को आवश्यकताओं को समझना चाहते हैं (और आप व्यवसाय डोमेन में कोई विशेषज्ञ नहीं हैं), तो डीडीडी का मौलिक सार आपके दृष्टिकोण को बदल सकता है।
+1। महान सवाल – RichardOD