एनीमिक डोमेन मॉडल से निपटने

Question

मैं अपने डीएएल को अपने बिजनेस लेयर से अलग करने की कोशिश कर रहा था, और ऐसा करने में, मैंने किसी भी ActiveRecord दृष्टिकोण को छोड़ने और डेटामैपर दृष्टिकोण के लिए जाने का निर्णय लिया। दूसरे शब्दों में, मेरे डोमेन ऑब्जेक्ट्स स्वयं को बनाए रखने का ख्याल नहीं रखेंगे। ऐसा करने में, मैं "एनीमिक डोमेन मॉडल" एंटी-पैटर्न पर अतिक्रमण कर रहा हूं। उदाहरण के लिए, मेरे कार्यक्रम में इकाइयों में से एक संगठन है।

एक संगठन कुछ इस तरह के रूप में प्रस्तुत किया जाता है:

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
} 

तो मूल रूप से इस संगठन (मार्टिन Fowler का कहना है के रूप में) कुछ डेटा के लिए "बैग" के रूप में कार्य के अलावा अन्य कुछ नहीं करता है। PHP दुनिया में यह एक गौरवशाली सरणी से अधिक कुछ नहीं है। इसके साथ जुड़े शून्य व्यवहार हैं।

और कार्यक्रम में व्यवहार, मैं संगठन सेवा जैसी "सेवा स्तर" कक्षा में चिपक रहा हूं जो ज्यादातर इन वस्तुओं और डीएएल के मध्य मध्यस्थ के रूप में कार्य करता है।

PHP के साथ संभावित स्केलिंग समस्याओं के अलावा (मेरे पास अन्य कारण हैं कि मैं इन वस्तुओं में अपने डेटा को "बैगिंग" करने का आग्रह करता हूं), क्या यह दृष्टिकोण पूरी तरह से बंद है?

इन परिस्थितियों में आप अपने डोमेन मॉडल को कैसे प्रबंधित करते हैं? शायद एक संगठन मेरे डोमेन का पहला स्थान नहीं है?

Answer 1

अच्छी तरह से, यह शुरुआत में इस तरह लगता है, लेकिन जब आप अपने कोड अधिक refactor होगा, आप अपने संगठन के वर्ग के लिए कुछ व्यवहार करने के लिए मिल जाएगा ...

एक उदाहरण है कि मैं अब के बारे में सोच सकता है अगर आपके पास लोग (कर्मचारी) हैं, तो आप उन्हें संगठन के साथ जोड़ना चाहेंगे। इसलिए, आपके पास एक विधि AssociateEmployee(User employee) हो सकती है जो आपके संगठन वर्ग में इसकी जगह पा सकती है।

या आप के बजाय तीन चरणों में पता, शहर, राज्य की तरह मानकों की स्थापना की कंपनी के स्थान बदल सकता है,, आप ChangeLocation(Street, City, State) विधि जोड़ सकते हैं ..

बस, चरण दर चरण जाना है जब आप में कुछ कोड का सामना आप बीएल/सेवा परत जो ऐसा लगता है कि यह डोमेन में होना चाहिए, इसे डोमेन पर ले जाएं। यदि आप फाउलर पढ़ते हैं, तो आप इसे जल्द ही प्राप्त करेंगे जब आप इसे अपने कोड में देखते हैं।

Answer 2

अब यह सिर्फ एनीमिक हो सकता है?

उदाहरण के लिए, एक बार जब मैं एक बैठक/सम्मेलन पंजीकरण साइट विकसित कर रहा था। यह केवल एक बैठक के साथ शुरू हुआ।

अभी भी एक मीटिंग क्लास और केवल एक उदाहरण था, लेकिन अगले वर्ष हमने सम्मेलन आयोजित किया, इसे विस्तारित किया गया और नई संपत्तियों को जोड़ा गया (दो बैक-टू-बैक मीटिंग्स आयोजित करने के लिए), तो स्पष्ट रूप से यह सिर्फ इतना नहीं था अभी तक पूरी तरह से विकसित किया गया है, क्योंकि हमने फिर उन मीटिंग समूहों को जोड़ा जो कई मीटिंग्स ले सकते थे।

तो मुझे लगता है कि यह ध्यान रखना महत्वपूर्ण है कि डोमेन समय के साथ बदलते हैं और आपका मॉडल दोबारा बदल सकता है, इसलिए यदि आप सोच सकते हैं कि यह एनीमिक है, तो यह शायद थोड़ा आगे दिखने वाला हो सकता है (जैसे आपका संगठन कक्षा कुछ सेटिंग्स, नियम या प्राथमिकताएं या कुछ प्राप्त करना शुरू कर देगी)।

Answer 3

आपकी इकाई एनीमिक नहीं है क्योंकि आप एक प्रतिस्थापन ले रहे हैं जो शुरू करने के लिए नहीं होना चाहिए। संस्थाओं को कायम रखना और लाने की रिपोजिटरी की प्रतिकृति है। वास्तव में आपका व्यवहार आपकी इकाइयों में होना चाहिए जो सेवा परत में नहीं है। लेकिन यह बताते हुए कि सरल उत्तर से परे रास्ता कहां जाता है। एरिक इवांस द्वारा डीडीडी एक अच्छा प्रारंभिक बिंदु है।

Answer 4

आप यह भी मान सकते हैं कि यदि आपके पास बहुत से व्यवसाय नियम नहीं हैं, या डोमेन बस इतना जटिल नहीं है, तो डीडीडी आपके लिए बहुत अधिक ओवरहेड हो सकता है। डीडीडी बड़े, जटिल डोमेन के लिए एक उत्कृष्ट समाधान है, लेकिन यदि आप डेटा में डेटा कर रहे हैं तो बहुत अधिक ओवरहेड और जटिलता है। डीडीडी डिजाइन करना कठिन है और स्वाभाविक रूप से जटिलता को जोड़ता है, इसलिए इसे उचित ठहराने के लिए, समस्या डोमेन की जटिलता उस से अधिक होनी चाहिए।

यह सब मैं ज़प्पन और एपिटका में जोड़ूंगा।