डोमेन सेवाओं का उपयोग कर सकते हैं Repositories?

Question

डोमेन सेवा एक्सेस रिपोजिटरी कर सकते हैं? या उन्हें आवेदन सेवाओं द्वारा पास किए गए समेकन/संस्थाओं पर काम करना चाहिए?

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

संस्करण 1 डोमेन सेवा के अंदर भंडार का उपयोग करता है। संस्करण 2 एप्लिकेशन सेवा में निर्भरता को हल करता है और उन्हें TransferDomainService पर भेजता है।

इस उदाहरण में ऑपरेशन सरल है (एक खाते से धन घटाएं और इसे दूसरे में जोड़ें)। लेकिन यदि अधिक व्यवसाय नियम शामिल होंगे (संभवतः अधिक समेकित तक पहुंच की आवश्यकता है)? यदि संस्करण 2 लागू किया गया है, तो एप्लिकेशन सेवा में ज्ञान होना चाहिए कि वास्तव में डोमेन सेवा की आवश्यकता क्या है। यदि संस्करण 1 चुना जाता है, तो डोमेन सेवा रिपोजिटरी से पूछती है कि इसके कार्य को करने के लिए क्या आवश्यक है।

(नोट्स के टुकड़े के बारे में:। जावा DDD बिल्डिंग ब्लॉक के शब्दाडंबर पट्टी ग्रूवी कोड नामों में शामिल)

संस्करण 1

class TransferApplicationService { 
    def transferDomainService 
    def customerDomainService 
    def emailNotifierInfrastructureService 

    def transfer(fromAccount, toAccount, amount) { 
     transferDomainService.transfer(fromAccount, toAccount, amount) 
     def email = customerDomainService.accountNotificationEmail(toAccount) 
     emailNotifierInfrastructureService.notifyAboutTransfer(email, amount) 
    } 
} 

class TransferDomainService { 
    def accountRepository 
    def transfer(fromAccount, toAccount, amount) { 
     def from = accountRepository.findByNumber(fromAccount) 
     def to = accountRepository.findByNumber(toAccount) 
     to.decreaseBalance(amount) 
     from.increaseBalance(amount) 
    } 
} 

संस्करण 2

class TransferApplicationService { 
    def accountRepository 
    def transferDomainService 
    def customerDomainService 
    def notifierInfrastructureService 

    def transfer(fromAccount, toAccount, amount) { 
     def from = accountRepository.findByNumber(fromAccount) 
     def to = accountRepository.findByNumber(toAccount) 
     transferDomainService.transfer(from, to, amount) 
     def email = customerDomainService.accountNotificationEmail(toAccount) 
     notifierInfrastructureService.notifyAboutTransfer(email, amount) 
    } 
} 

class TransferDomainService { 
    def transfer(fromAccount, toAccount, amount) { 
     to.decreaseBalance(amount) 
     from.increaseBalance(amount) 
    } 
} 

Answer 1

खैर, मैं कहूंगा कि अगर चुनने वाली संस्थाएं डोमेन लॉगी के अच्छे सौदे के लिए आती हैं सी, तो मैं उस कार्य को डोमेन सेवा में सौंप सकता हूं। हालांकि, मैं आमतौर पर आवेदन सेवाओं में कुल रूट संदर्भों को हल करने का प्रयास करता हूं।

हालांकि, मुझे लगता है कि आपके यहां कुछ अन्य समस्याएं हो सकती हैं या कम से कम आप अपने डिज़ाइन को बेहतर बनाने के लिए डोमेन ईवेंट जैसे कुछ अन्य डीडीडी सामरिक पैटर्न का उपयोग कर सकते हैं।

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

अपने घटकों को डीकॉप्लिंग करने के अलावा, आप अपने डोमेन की सर्वव्यापी भाषा को समृद्ध कर रहे हैं। एक अधिसूचना भेजना अब एक ही प्रक्रिया के हिस्से के बजाय किए गए धन हस्तांतरण के जवाब में होता है और कई अन्य इच्छुक पार्टियां भी प्रतिक्रिया दे सकती हैं।

अंत में, आपकी डोमेन सेवा वर्तमान में प्रति लेनदेन केवल एक समग्र रूट को संशोधित करने के नियम का उल्लंघन कर रही है। मैं यह नहीं कह रहा हूं कि आप कभी भी नियम तोड़ नहीं सकते हैं, लेकिन आम तौर पर यह एक अच्छा संकेतक है कि आपको अंतिम स्थिरता का उपयोग करना चाहिए, या शायद आपकी कुल सीमाएं गलत हैं।

यदि आप इसके बारे में सोचते हैं, तो खातों के बीच धन हस्तांतरण शायद ही कभी परमाणु तरीके से होता है (यदि वे कभी करते हैं)। मुझे लगता है कि यह मामला हो सकता है यदि दोनों खाते एक ही बैंक में हैं, लेकिन हस्तांतरण जब कई बैंकों को हस्तांतरित करता है तो अंतिम स्थिरता का उपयोग किया जाना चाहिए।