डोमेन संचालित डिजाइन: डोमेन सेवा, अनुप्रयोग सेवा

Question

क्या कोई डोमेन और एप्लिकेशन सेवाओं के बीच अंतर को कुछ उदाहरण प्रदान करके समझा सकता है? और, यदि कोई सेवा एक डोमेन सेवा है, तो क्या मैं इस सेवा का वास्तविक क्रियान्वयन डोमेन असेंबली में करूंगा और यदि हां, तो क्या मैं उस डोमेन सेवा में रिपॉजिटरी को भी इंजेक्ट करूंगा? कुछ जानकारी वास्तव में उपयोगी होगी।

Answer 1

सेवाएँ 3 स्वादों में आती हैं: डोमेन सेवाएँ , अनुप्रयोग सेवाएँ और इन्फ्रास्ट्रक्चर सेवाएँ ।

• डोमेन सेवाएँ : व्यावसायिक तर्क को एन्क्रिप्ट करती हैं जो स्वाभाविक रूप से एक डोमेन ऑब्जेक्ट के भीतर फिट नहीं होते हैं, और विशिष्ट CRUD ऑपरेशन नहीं हैं - जो एक रिपॉजिटरी के हैं ।
• अनुप्रयोग सेवाएँ : बाहरी उपभोक्ताओं द्वारा आपके सिस्टम से बात करने के लिए उपयोग की जाती है ( वेब सेवा सोचें )। अगर उपभोक्ताओं को सीआरयूडी संचालन की आवश्यकता होती है, तो उन्हें यहां उजागर किया जाएगा।
• अवसंरचना सेवाएं : तकनीकी चिंताओं का सार करने के लिए प्रयुक्त (जैसे MSMQ, ईमेल प्रदाता, आदि)।

डोमेन सेवाओं को अपने डोमेन ऑब्जेक्ट्स के साथ रखना समझदारी है - वे सभी डोमेन लॉजिक पर केंद्रित हैं। और हाँ, आप अपनी सेवाओं में Repositories को इंजेक्ट कर सकते हैं।

अनुप्रयोग सेवाएँ आमतौर पर बाहरी अनुरोधों से निपटने के लिए डोमेन सेवाओं और प्रस्तावों दोनों का उपयोग करेंगी ।

उम्मीद है की वो मदद करदे!

Comments

आप CQRS द्वारा कमांड और क्वेश्चन कहां डालेंगे? कौन सी सेवा उन्हें उत्पन्न करती है और कौन सी सेवा उन्हें संभालती है?

— inf3rno

मुझे लगता है कि एप्लिकेशन सेवाओं को "वेब सेवाओं" जैसे तकनीकी विवरणों के प्रति उदासीन होना चाहिए, वे ऐसी सेवाओं द्वारा उपयोग किए जाते हैं। डोमेन-संचालित डिज़ाइन में सेवाएँ

— deamon

@prograhammer - एक डोमेन सेवा के लिए एक उदाहरण फंड्सट्रांसफर सर्विस हो सकता है, जहां डोमेन मॉडल एक BankAccount है, स्थानांतरण में कुछ व्यावसायिक तर्क हो सकते हैं जो सीधे खाता ऑब्जेक्ट (इवांस डीडीडी बुक से लिया गया) में फिट नहीं होता है।

— बॉर्नटूकोड

इसलिए उदाहरण के लिए कहो Loginuser () एक डोमेन सेवा का एक उदाहरण होगा। जहां getUsers () एक आवेदन सेवा होगी ??

— filthy_wizard

दोनों बल्कि अनुप्रयोग सेवाएँ हैं क्योंकि प्रमाणीकरण और अक्सर प्राधिकरण निर्णय भी मूल डोमेन के नहीं होते हैं।

— मगांरा ०

Answer 2

^{(यदि आपको पढ़ने का मन नहीं है, तो नीचे एक सारांश है :-)}

मैंने भी एप्लिकेशन सेवाओं की सटीक परिभाषा के साथ संघर्ष किया है। यद्यपि विजय का जवाब एक महीने पहले मेरी विचार प्रक्रिया के लिए बहुत मददगार था, लेकिन मैं इसके एक हिस्से से असहमत हूं।

अन्य संसाधन

एप्लिकेशन सेवाओं के बारे में बहुत कम जानकारी है। समग्र जड़ों, रिपॉजिटरी और डोमेन सेवाओं जैसे विषयों पर बड़े पैमाने पर चर्चा की जाती है, लेकिन आवेदन सेवाओं का केवल संक्षेप में उल्लेख किया जाता है या पूरी तरह से छोड़ दिया जाता है।

MSDN मैगज़ीन का लेख डोमेन-चालित डिज़ाइन का एक परिचय एक WCF सेवा के रूप में बाहरी ग्राहकों के लिए अपने डोमेन मॉडल को रूपांतरित करने और / या उजागर करने के तरीके के रूप में एप्लिकेशन सेवाओं का वर्णन करता है। इस तरह विजय एप्लिकेशन सेवाओं का भी वर्णन करता है। इस दृष्टिकोण से, अनुप्रयोग सेवाएँ आपके डोमेन के लिए एक इंटरफ़ेस हैं ।

प्याज वास्तुकला पर जेफरी पलेर्मो के लेख (भाग एक , दो और तीन ) एक अच्छा पढ़ा है। वह एप्लिकेशन सेवाओं को एप्लिकेशन-स्तरीय अवधारणाओं के रूप में मानता है , जैसे कि उपयोगकर्ता का सत्र। यद्यपि यह एप्लिकेशन सेवाओं की मेरी समझ के करीब है, यह अभी भी इस विषय पर मेरे विचारों के अनुरूप नहीं है।

मेरे विचार

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

डोमेन

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

मेरा समाधान
- My.Product.Core (My.Product.dll)
  - डोमेन सेवा
      IExchangeRateService
    उत्पाद
    ProductFactory
    IProductRepository

Productऔर ProductFactoryकक्षाओं कोर विधानसभा में लागू किया गया है। एक IProductRepositoryऐसी चीज है जो संभवतः एक डेटाबेस द्वारा समर्थित है। इसे लागू करना डोमेन की चिंता नहीं है और इसलिए इसे एक इंटरफ़ेस द्वारा परिभाषित किया गया है।

अभी के लिए, हम इस पर ध्यान केंद्रित करेंगे IExchangeRateService। इस सेवा के लिए व्यावसायिक तर्क बाहरी वेब सेवा द्वारा कार्यान्वित किया जाता है। हालाँकि, इसकी अवधारणा अभी भी डोमेन का हिस्सा है और इस इंटरफ़ेस द्वारा दर्शाया गया है।

भूमिकारूप व्यवस्था

बाहरी निर्भरता का कार्यान्वयन अनुप्रयोग के बुनियादी ढांचे का हिस्सा है:

मेरा समाधान
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - डोमेन सेवा
      XEExchangeRateService
    SqlServerProductRepository

XEExchangeRateServicexe.com केIExchangeRateService साथ संचार करके डोमेन सेवा को लागू करता है । इस कार्यान्वयन का उपयोग आपके अनुप्रयोगों द्वारा किया जा सकता है जो आपके डोमेन मॉडल का उपयोग करते हैं, बुनियादी ढांचे की विधानसभा को शामिल करके।

आवेदन

ध्यान दें कि मैंने अभी तक एप्लिकेशन सेवाओं का उल्लेख नहीं किया है। हम अब उन पर गौर करेंगे। मान लें कि हम एक IExchangeRateServiceकार्यान्वयन प्रदान करना चाहते हैं जो त्वरित लुकअप के लिए कैश का उपयोग करता है। इस डेकोरेटर वर्ग की रूपरेखा इस तरह दिख सकती है।

public class CachingExchangeRateService : IExchangeRateService
{
    private IExchangeRateService service;
    private ICache cache;

    public CachingExchangeRateService(IExchangeRateService service, ICache cache)
    {
        this.service = service;
        this.cache = cache;
    }

    // Implementation that utilizes the provided service and cache.
}

ICacheपैरामीटर ध्यान दें ? यह अवधारणा हमारे डोमेन का हिस्सा नहीं है, इसलिए यह एक डोमेन सेवा नहीं है। यह एक एप्लिकेशन सेवा है । यह हमारे बुनियादी ढांचे की एक निर्भरता है जो आवेदन द्वारा प्रदान की जा सकती है। आइए एक आवेदन पेश करें जो इसे प्रदर्शित करता है:

मेरा समाधान
- My.Product.Core (My.Product.dll)
  - डोमेन सेवा
      IExchangeRateService
    उत्पाद
    ProductFactory
    IProductRepository
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - अनुप्रयोग सेवाएँ
      ICache
  - डोमेन सेवा
      CachingExchangeRateService
      XEExchangeRateService
    SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
  - अनुप्रयोग सेवाएँ
      MemcachedCache
    IMyWcfService.cs
  + MyWcfService.svc
  + Web.config

यह सब इस तरह से आवेदन में एक साथ आता है:

// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);

ServiceLocator.For<IExchangeRateService>().Use(cachingService);

सारांश

एक पूर्ण अनुप्रयोग में तीन प्रमुख परतें होती हैं:

• डोमेन
• आधारिक संरचना
• आवेदन

डोमेन परत में डोमेन इकाइयाँ और स्टैंड-अलोन डोमेन सेवाएँ शामिल हैं। कोई भी डोमेन अवधारणा (इसमें डोमेन सेवाएँ, लेकिन रिपॉजिटरी भी शामिल हैं) जो बाहरी संसाधनों पर निर्भर करती हैं, इंटरफेस द्वारा परिभाषित की जाती हैं।

बुनियादी ढांचे की परत में डोमेन परत से इंटरफेस का कार्यान्वयन शामिल है। ये कार्यान्वयन नए गैर-डोमेन निर्भरताएँ पेश कर सकते हैं जिन्हें आवेदन प्रदान किया जाना है। ये अनुप्रयोग सेवाएँ हैं और इंटरफेस द्वारा दर्शाई गई हैं।

एप्लिकेशन परत में एप्लिकेशन सेवाओं का कार्यान्वयन शामिल है। आवेदन परत में डोमेन इंटरफेस के अतिरिक्त कार्यान्वयन भी हो सकते हैं, यदि बुनियादी ढांचे की परत द्वारा प्रदान किए गए कार्यान्वयन पर्याप्त नहीं हैं।

हालाँकि यह परिप्रेक्ष्य सेवाओं की सामान्य DDD परिभाषा से मेल नहीं खा सकता है, यह डोमेन को एप्लिकेशन से अलग करता है और आपको कई अनुप्रयोगों के बीच डोमेन (और इन्फ्रास्ट्रक्चर) असेंबली साझा करने की अनुमति देता है।

Comments

@ डारियो-जी: आपको अनुरोध मॉडल से अपने डोमेन मॉडल को फिर से बनाना / फिर से बनाना होगा और डोमेन मॉडल को डोमेन सेवा में पास करना होगा। यह प्रश्न आपको कुछ विचार प्रदान कर सकता है। यदि नहीं, तो मुझे बताएं और मैं देखूंगा कि क्या मेरे पास दूसरे प्रश्न का उत्तर जोड़ने के लिए कुछ समय है।

— नील्स वैन डेर रेस्ट

@Tiendq: क्या आप IExchangeRateServiceइंटरफ़ेस से मतलब रखते हैं ? यह एक डोमेन कॉन्सेप्ट है, यानी कुछ ऐसा जो आपके ग्राहक की सर्वव्यापी भाषा में शामिल है। आपके डोमेन के अन्य भाग इस सेवा पर निर्भर हो सकते हैं, यही वजह है कि डोमेन लेयर में परिभाषित इसका इंटरफ़ेस। लेकिन क्योंकि इसके कार्यान्वयन में एक बाहरी वेब सेवा शामिल है, इसलिए कार्यान्वयन वर्ग बुनियादी ढांचे की परत में रहता है। इस तरह से डोमेन लेयर केवल बिजनेस लॉजिक से संबंधित है।

— नील्स वैन डेर रेस्ट

@Tiendq: एक पारंपरिक स्तरित वास्तुकला में, बुनियादी ढांचा आमतौर पर डोमेन-अज्ञेयवादी होता है। लेकिन प्याज वास्तुकला में (मेरे उत्तर में लिंक देखें) बुनियादी ढांचा डोमेन के बाहरी निर्भरता को लागू करता है। लेकिन मैं यह नहीं कहूंगा कि बुनियादी ढांचा डोमेन पर निर्भर करता है , यह सिर्फ इसका संदर्भ देता है। मैंने 'आर्किटेक्चर' शब्द को प्याज वास्तुकला से लिया है, लेकिन 'बाहरी' एक बेहतर नाम हो सकता है।

— नील्स वैन डेर रेस्ट

@ डेरेक: उन 'चीजों में से एक' एक ExchangeRateउदाहरण हो सकता है , जिसमें एक आधार मुद्रा, एक काउंटर मुद्रा और इन दो मुद्राओं के बीच विनिमय दर का मूल्य शामिल है। ये कसकर संबंधित मान डोमेन से 'विनिमय दर' अवधारणा का प्रतिनिधित्व करते हैं, इसलिए ये डोमेन परत में रहते हैं। हालांकि यह एक साधारण डीटीओ की तरह लग सकता है, डीडीडी में इसे वैल्यू ऑब्जेक्ट कहा जाता है और इसमें अन्य उदाहरणों की तुलना करने या अतिरिक्त व्यापार तर्क हो सकता है।

— नील्स वैन डेर रेस्ट

मैं उस भाग से असहमत हूँ जहाँ आप विजय से असहमत हैं और यहाँ क्यों है। CachingExchangeRateService एक बुनियादी ढांचे की चिंता है। भले ही आप उदारता से एक ICache को स्वीकार कर रहे हों, लेकिन ICache के लिए क्रियान्वयन इसमें शामिल तकनीक (यानी वेब, विंडोज) पर निर्भर करता है। सिर्फ इसलिए कि यह सामान्य है यह एक आवेदन सेवा नहीं करता है। एक एप्लिकेशन सेवा आपके डोमेन की एपीआई है। क्या होगा यदि आप अपने डोमेन को किसी अन्य व्यक्ति को ऐप लिखना चाहते हैं, तो वे क्या उपयोग करेंगे? अनुप्रयोग सेवाएँ, और उन्हें कैशिंग की आवश्यकता नहीं हो सकती है, इसलिए आपका कैचिंग इम्प्लान्ट उनके लिए बेकार है (अर्थात यह बुनियादी ढाँचा है)

— हारून हॉकिन्स

Answer 3

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

मेरा 'अहा' पल दो चीजों से शुरू हुआ था:

• उपरोक्त लिंक में सेवाओं के विवरण को पढ़ना, अधिक सटीक रूप से यह वाक्य है:

  डोमेन सेवाओं को सर्वव्यापी भाषा और डोमेन प्रकारों के संदर्भ में व्यक्त किया जाता है, अर्थात विधि तर्क और वापसी मान उचित डोमेन कक्षाएं हैं।

• इस ब्लॉग पोस्ट को पढ़ना , विशेष रूप से यह हिस्सा:

  क्या मैं एक बड़ी मदद मिल सकता है सेब को संतरे से अलग करने के लिए आवेदन वर्कफ़्लो के संदर्भ में सोच रहा है। एप्लिकेशन वर्कफ़्लो से संबंधित सभी तर्क आमतौर पर ऐप्लिकेशन लेयर में लागू होते हैं, जबकि डोमेन से प्राप्त अवधारणाएँ एक या एक से अधिक डोमेन सेवाएँ बनाने वाले मॉडल ऑब्जेक्ट के रूप में फ़िट नहीं होती हैं।

Comments

मैं सहमत हूं, यह ठीक है कि मैं एप्लिकेशन सेवाओं को कैसे परिभाषित करता हूं, और यह उन सभी स्थितियों को फिट करता है जो मुझे अब तक मिले हैं। डोमेन सेवाएं डोमेन ऑब्जेक्ट्स से संबंधित सभी चीजों से निपटती हैं, लेकिन यह एकल इकाई के दायरे से परे हैं। Ex: BookReferencesService.GetNextAvailableUniqueTrackingNumber (), ध्यान स्पष्ट रूप से व्यावसायिक नियम * है। एप्लिकेशन सेवा के बारे में, यह वही है जो आप वर्णन करते हैं, ज्यादातर समय मैं इस व्यवसाय वर्कफ़्लो को अपने नियंत्रक कार्यों में डालकर शुरू करता हूं, और जब मैं इसे नोटिस करता हूं तो मैं इस तर्क को एप्लिकेशन सर्विस लेयर में रिफ्लेक्टर करता हूं। हम कह सकते हैं कि यह परत उपयोग के मामलों के लिए है

— tobiak777

* और ऐसे डोमेन सेवा इंटरफेस डोमेन संस्थाओं द्वारा खपत किए जाते हैं।

— तोबियाक777

Answer 4

डोमेन सेवा डोमेन का विस्तार है। इसे केवल डोमेन के संदर्भ में देखा जाना चाहिए। यह कुछ उपयोगकर्ता कार्रवाई नहीं है उदाहरण के लिए नज़दीकी खाता या कुछ और। डोमेन सेवा वहां फिट होती है जहां कोई स्थिति नहीं है। अन्यथा यह एक डोमेन ऑब्जेक्ट होगा। डोमेन सेवा कुछ ऐसा करती है जो केवल अन्य सहयोगियों (डोमेन ऑब्जेक्ट या अन्य सेवाओं) के साथ किए जाने पर समझ में आता है। और यह समझदारी एक और परत की जिम्मेदारी है।

एप्लिकेशन सेवा वह परत है जो डोमेन ऑब्जेक्ट्स और सेवाओं के बीच इंटरैक्शन को प्रारंभ और देखरेख करती है। प्रवाह आम तौर पर इस तरह होता है: रिपॉजिटरी से डोमेन ऑब्जेक्ट (या ऑब्जेक्ट) प्राप्त करें, एक एक्शन निष्पादित करें और इसे (उन्हें) वापस वहां (या नहीं) डालें। यह अधिक कर सकता है - उदाहरण के लिए, यह जांच सकता है कि डोमेन ऑब्जेक्ट मौजूद है या नहीं और तदनुसार अपवाद फेंकें। तो यह उपयोगकर्ता को एप्लिकेशन के साथ इंटरैक्ट करने देता है (और संभवतः यही उसका नाम कहां से उत्पन्न होता है) - डोमेन ऑब्जेक्ट्स और सेवाओं में हेरफेर करके। एप्लिकेशन सेवाओं को आम तौर पर सभी संभावित उपयोग के मामलों का प्रतिनिधित्व करना चाहिए। संभवत: डोमेन के बारे में सोचने से पहले आप जो सबसे अच्छी चीज कर सकते हैं, वह है एप्लिकेशन सेवा इंटरफेस बनाना जो आपको वास्तव में क्या करने की कोशिश कर रहा है, उसमें बहुत बेहतर अंतर्दृष्टि देगा। इस तरह के ज्ञान होने से आप डोमेन पर ध्यान केंद्रित कर सकते हैं।

रिपॉजिटरी आमतौर पर डोमेन सेवाओं में इंजेक्ट किया जा सकता है लेकिन यह दुर्लभ परिदृश्य है। यह एप्लिकेशन लेयर है जो इसे ज्यादातर समय करता है।

Comments

"डोमेन सेवा वहां फिट होती है जहां कोई स्थिति नहीं है। अन्यथा यह एक डोमेन ऑब्जेक्ट होगा।" इसने मेरे लिए क्लिक किया। धन्यवाद।

— निक

Answer 5

रेड बुक से (वॉन वर्नोन द्वारा डोमेन ड्रिवेन डिज़ाइन लागू करना), यह है कि मैं अवधारणाओं को कैसे समझता हूं:

डोमेन ऑब्जेक्ट्स ( निकाय और मान ऑब्जेक्ट ), (उप) डोमेन द्वारा आवश्यक व्यवहार को कूटबद्ध करते हैं, जिससे यह स्वाभाविक, अभिव्यंजक और समझ में आता है।

डोमेन सेवाएं ऐसे व्यवहार को एनकाउंटर करती हैं जो किसी एकल डोमेन ऑब्जेक्ट में फिट नहीं होते हैं । उदाहरण के लिए, (संबंधित परिवर्तनों के साथ ) के Bookलिए उधार देने वाली पुस्तक लाइब्रेरी एक डोमेन सेवा से ऐसा कर सकती है।ClientInventory

अनुप्रयोग सेवाएँ डोमेन के शीर्ष पर आवश्यक अतिरिक्त चिंताओं सहित उपयोग के मामलों के प्रवाह को संभालती हैं । बाहरी क्लाइंट द्वारा खपत के लिए यह अक्सर अपने एपीआई के माध्यम से ऐसे तरीकों को उजागर करता है। हमारे पिछले उदाहरण पर निर्माण करने के लिए, हमारी एप्लिकेशन सेवा एक ऐसी विधि का खुलासा कर सकती है LendBookToClient(Guid bookGuid, Guid clientGuid)जो:

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

एक आवेदन सेवा में आम तौर पर एक बहुत ही सरल प्रवाह होना चाहिए। जटिल अनुप्रयोग सेवा प्रवाह अक्सर इंगित करते हैं कि डोमेन तर्क डोमेन से बाहर लीक हो गया है।

जैसा कि आप उम्मीद कर सकते हैं कि डोमेन मॉडल इस तरह से बहुत साफ है , और डोमेन विशेषज्ञों के साथ समझना और चर्चा करना आसान है, क्योंकि इसमें केवल अपने स्वयं के, वास्तविक व्यावसायिक चिंताएं शामिल हैं। आवेदन प्रवाह , दूसरे हाथ पर, है भी बहुत आसानी से प्रबंधित है, क्योंकि यह डोमेन चिंताओं में से राहत मिली है, और संक्षिप्त, और सीधा हो जाता है।

Comments

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

— टिमो

Answer 6

डोमेन सेवाएँ: वे विधियाँ जो वास्तव में किसी एक इकाई पर नहीं बैठती हैं या रिपॉजिटरी तक पहुँच की आवश्यकता होती है, वे डोमेन सेवाओं में निहित हैं। डोमेन सेवा परत में स्वयं का डोमेन लॉजिक भी हो सकता है और यह संस्थाओं और मूल्य वस्तुओं के रूप में डोमेन मॉडल का उतना ही हिस्सा है।

अनुप्रयोग सेवाएँ: अनुप्रयोग सेवा एक पतली परत है जो डोमेन मॉडल के ऊपर बैठती है और अनुप्रयोग गतिविधि का समन्वय करती है। इसमें व्यावसायिक तर्क शामिल नहीं है और किसी भी संस्था की स्थिति नहीं रखता है; हालाँकि, यह एक व्यवसाय वर्कफ़्लो लेनदेन की स्थिति को संग्रहीत कर सकता है। आप अनुरोध-उत्तर मैसेजिंग पैटर्न का उपयोग करके डोमेन मॉडल में एक एपीआई प्रदान करने के लिए एक एप्लिकेशन सेवा का उपयोग करते हैं।

बाजरा, सी (2010)। पेशेवर ASP.NET डिजाइन पैटर्न। विली प्रकाशन। 92।

Answer 7

डोमेन सेवाएँ : एक ऐसी सेवा जो एक व्यावसायिक तर्क को व्यक्त करती है जो किसी भी एग्रीगेट रूट का हिस्सा नहीं है।

• आपके पास 2 अलग हैं:

  • Product जिसमें नाम और कीमत शामिल है।
  • Purchase जिसमें खरीदारी की तारीख, उस समय मात्रा और उत्पाद की कीमत के साथ ऑर्डर किए गए उत्पादों की सूची और भुगतान विधि शामिल है।

• Checkout इन दोनों मॉडलों में से किसी का भी हिस्सा नहीं है और आपके व्यवसाय में अवधारणा है।

• Checkoutएक डोमेन सेवा के रूप में बनाया जा सकता है जो सभी उत्पाद प्राप्त करता है और कुल कीमत की गणना करता है, PaymentServiceइन्फ्रास्ट्रक्चर के कार्यान्वयन भाग के साथ किसी अन्य डोमेन सेवा को कॉल करके कुल भुगतान करता है , और इसे रूपांतरित करता है Purchase।

अनुप्रयोग सेवाएँ : एक सेवा जो "ऑर्केस्ट्रा" या डोमेन विधियों का प्रयोग करती है। यह केवल आपके नियंत्रक के रूप में सरल हो सकता है।

यह वह जगह है जहाँ आप आमतौर पर करते हैं:

public String createProduct(...some attributes) {
  if (productRepo.getByName(name) != null) {
    throw new Exception();
  }

  productId = productRepository.nextIdentity();

  product = new Product(productId, ...some attributes);

  productRepository.save(product);

  return productId.value();
  // or Product itself
  // or just void if you dont care about result
}

public void renameProduct(productId, newName) {
  product = productRepo.getById(productId);

  product.rename(newName);

  productRepo.save(product);
}

आप यहाँ जाँच कर सकते हैं कि क्या जाँच Productअद्वितीय है। जब तक एक Productअद्वितीय होने के नाते एक अपरिवर्तनीय है तो उस डोमेन सेवा का हिस्सा होना चाहिए जिसे बुलाया जा सकता है UniqueProductCheckerक्योंकि यह Productकक्षा का हिस्सा नहीं हो सकता है और यह कई एग्रीगेट्स के साथ बातचीत करता है।

डीडीडी परियोजना का पूरा-पूरा उदाहरण यहां दिया गया है: https://github.com/VaughnVernon/IDDD_Samples

आप अनुप्रयोग सेवा और डोमेन सेवा के एक जोड़े के कई उदाहरण पा सकते हैं

Comments

क्या केवल एप्लिकेशन सेवाओं में संस्थाओं को मान्य और सहेजना अनिवार्य है? अगर मेरे पास A, B और C और उनमें से सभी एक-दूसरे से संबंधित हैं (A -> B -> C) और A पर कार्रवाई दूसरे से एक डोमेन सेवा को कॉल करके B और C में परिवर्तन का कारण बन सकती है, तो इसे कैसे करें?

— MrNVK

> क्या केवल एप्लिकेशन सेवाओं में संस्थाओं को मान्य और सहेजना अनिवार्य है? अगर आपको करना है, तो हाँ। अधिकांश बार आपको यह देखना होगा कि कोई आईडी मौजूद है क्योंकि अन्यथा आप अशक्त चर पर काम करेंगे।

— प्रात: काल

> यदि मेरे पास A, B और C और उनमें से सभी एक-दूसरे से संबंधित हैं (A -> B -> C) और A पर कार्रवाई दूसरे से एक डोमेन सेवा को कॉल करके B और C में परिवर्तन का कारण बन सकती है, तो इसे कैसे करें ? मुझे यकीन नहीं है कि "एक डोमेन सेवा को दूसरे से कॉल करने" से आपका क्या मतलब है, लेकिन एक एंटिटी के बदलाव के लिए प्रतिक्रियाओं के लिए, आप ईवेंट का उपयोग कर सकते हैं या एप्लिकेशन सेवा के साथ इसे ऑर्केस्ट्रेट कर सकते हैं, जैसे: समुच्चय। )। आर्केस्ट्रा बनाम कोरियोग्राफी: के लिए खोज

— doesnotmatter

आप उत्तर के लिए धन्यवाद! "एक डोमेन सेवा को दूसरे से कॉल करना" - मेरा मतलब है, अगर मेरे पास ए पर एक जटिल ऑपरेशन है, तो मुझे ADomainService का उपयोग करना होगा। लेकिन यह ऑपरेशन, इकाई A के अतिरिक्त, इकाई B को प्रभावित करता है। ADomainService में इकाई B पर किया जाने वाला ऑपरेशन भी जटिल है। तो मुझे ADomainService से BDomainService का उपयोग करना होगा। अब मुझे इस दृष्टिकोण पर संदेह है :) लेकिन अगर मैंने इस तर्क को ApplicationService में रखा, तो क्या यह व्यावसायिक प्रक्रियाओं के इनकैप्सुलेशन को नहीं तोड़ देगा जो केवल डोमेन लेयर में होना चाहिए, एप्लीकेशन लेयर में नहीं?

— MrNVK

आप अपने डोमेन सेवा से केवल ईवेंट का उत्सर्जन कर सकते हैं यदि आपको लगता है कि यह अनुप्रयोग सेवा के बजाय एक डोमेन सेवा में होना चाहिए।

— नॉटमैटर

Answer 8

एक डोमेन सेवा को एक ऐसी वस्तु के रूप में सोचें जो डोमेन ऑब्जेक्ट्स पर व्यावसायिक तर्क या व्यावसायिक नियमों से संबंधित तर्क को लागू करती है और यह तर्क एक ही डोमेन ऑब्जेक्ट्स में फिट होना मुश्किल है और साथ ही डोमेन सेवा के राज्य परिवर्तन का कारण नहीं बनता है (डोमेन सेवा एक ऑब्जेक्ट के बिना है एक "राज्य" या उस राज्य के बिना बेहतर जिसका व्यवसाय अर्थ है) लेकिन अंततः उस राज्य को केवल उन डोमेन ऑब्जेक्ट्स में बदल देता है जिन पर काम करता है।

जबकि एक एप्लिकेशन सेवा उपयोगकर्ता सहभागिता, इनपुट सत्यापन, व्यवसाय से संबंधित नहीं बल्कि अन्य चिंताओं के रूप में आवेदक स्तर के तर्क को लागू करती है: प्रमाणीकरण, सुरक्षा, ईमेलिंग, और इसी तरह .., केवल डोमेन ऑब्जेक्ट्स द्वारा उजागर सेवाओं का उपयोग करने के लिए खुद को सीमित करना।

इसका एक उदाहरण निम्नलिखित उदाहरण हो सकता है कि केवल व्याख्या करने के उद्देश्य से सोचा गया था : हमें एक बहुत कम डोमोटिक यूटिलिटी ऐप को लागू करना होगा जो एक साधारण ऑपरेशन को अंजाम दे, वह है "रोशनी चालू करें, जब कोई घर के कमरे का दरवाजा खोलता है जब कमरे से बाहर निकलने वाला दरवाजा बंद हो जाए तो प्रकाश बंद कर दें ”।

बहुत कुछ सरल करते हुए हम केवल 2 डोमेन एंटिटीज पर विचार करते हैं: Doorऔर Lamp, उनमें से प्रत्येक में 2 राज्य हैं, सम्मानजनक open/closedऔर on/off, और उन पर राज्य परिवर्तन संचालित करने के लिए विशिष्ट तरीके।

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

हम के रूप में हमारे डोमेन सेवा कॉल कर सकते हैं DomoticDomainServiceऔर 2 तरीकों को लागू: OpenTheDoorAndTurnOnTheLightऔर CloseTheDoorAndTurnOffTheLight, इन 2 तरीकों respectevely दोनों वस्तुओं की स्थिति बदलने Doorऔर Lampकरने के लिए open/onऔर closed/off।

एक कमरे से प्रवेश या बाहर निकलने की स्थिति यह डोमेन सेवा ऑब्जेक्ट और डोमेन ऑब्जेक्ट्स में मौजूद नहीं है, लेकिन किसी एप्लिकेशन सेवा द्वारा सरल उपयोगकर्ता इंटरैक्शन के रूप में लागू की जाएगी, जिसे हम कॉल कर सकते हैं HouseService, जो कुछ ईवेंट हैंडलर लागू करता है onOpenRoom1DoorToEnterऔर onCloseRoom1DoorToExit, और प्रत्येक कमरे के लिए (यह केवल उद्देश्य को समझाने के लिए एक उदाहरण है ..) , जो क्रमशः उपस्थित व्यवहार को निष्पादित करने के लिए कॉल डोमेन सेवा विधियों के बारे में चिंता करेगा (हमने इकाई नहीं माना है Roomक्योंकि यह केवल एक उदाहरण है) ।

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

Comments

Ciro: आप उदाहरण व्यावहारिक नहीं है और यह बहुत भ्रामक है।

— मोर्टेजा अज़ीज़ी

हाय मोर्टेजा, क्या आप अधिक विशिष्ट हो सकते हैं? आपका बिना किसी वास्तविक तर्क के केवल "निर्णय" होने का जोखिम है। धन्यवाद

— सिरो कोर्विनो