एक कॉन्फ़िगर करने योग्य नियम संचालित सिस्टम में डीडीडी

Question

यहां कोई अज्ञानता क्षमा करें, मैं डीडीडी के लिए बिल्कुल नया हूं इसलिए नम्र हो।

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

मुझे डीडीडी ऑफ़र की सादगी के विचार पसंद हैं, विशेष रूप से डोमेन की मूल अवधारणाओं से बुनियादी ढांचे की चिंताओं को अलग करना।

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

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

डीडीडी के बाद, मैं एक ऐसे परिदृश्य को मॉडल करने की कोशिश कर रहा हूं जहां एक कर्मचारी को पदोन्नत किया जाता है। आप प्रचारक (कर्मचारी.प्रोमोट) नामक कर्मचारी पर एक नई विधि आ सकते हैं। हमारे पास एक व्यापार नियम हो सकता है, यह दर्शाता है कि एक कर्मचारी को उसी वर्ष दो बार प्रचारित नहीं किया जा सकता है (हां यह सब तैयार है)।

public void promote(EmployeeLevel newLevel) { 
    if (hasBeenPromotedThisYear(this) { 
    throw new InvalidPromotionException 

ठीक है, आवेदन में मैं इस व्यवसाय शासन के साथ काम कर रहा हूँ एक नियम इंजन के लिए externalized किया जाएगा: इसलिए मैं कुछ ऐसा हो सकता था। डीडीडी के बाद, मैं कुछ ऐसा कर सकता था:

if(promotionRules.isEligibleForPromotion(this) 

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

public class Employee { 
    public void execute(Process process) 

या वैकल्पिक रूप से

public class EmployeeProcess { 
    public void process(Employee employee) 

मेरा प्रश्न है: DDD भी इस आवेदन में मतलब होता है? क्या मुझे इसके बजाय एक गैर डीडीडी भावना में प्रक्रियाओं, सत्यापन, व्यापार नियम (नियम इंजन) के सहयोग का मॉडल करना चाहिए?

मुझे प्याज आर्किटेक्चर पसंद है, और यूआई -> ऐप सर्विसेज -> कोर -> इन्फ्रास्ट्रक्चर का उपयोग चिंताओं का एक अच्छा अलगाव रखने के लिए कर सकते हैं। लेकिन मूल "डोमेन अवधारणाओं" के विरोध में कोर ऊपर उल्लिखित सहयोगी हो सकता है।

मेरा हिस्सा मानता है कि, इस मामले में, "डोमेन अवधारणाएं" वैधकर्ता, प्रोसेसर, व्यवसाय नियम हैं क्योंकि वे सर्वव्यापी भाषा बनाते हैं जब हम अपने सिस्टम पर चर्चा करते हैं। इस मामले में, मेरे पास ऐसी वास्तविकताओं (अधिकांश भाग के लिए), और प्रोसेसर, वैलिडेटर्स, नियम इंजन के संदर्भ में डोमेन अवधारणाएं होंगी जो सिस्टम में व्यवहार का एहसास करती हैं।

थोड़ा और जानकारी जोड़ना। ऊपर दिए गए मेरे प्रश्न को देखते हुए, मैं ऐसे समाधान की ओर काम कर रहा था जो इस तरह दिखेगा:

org.example।एप्लिकेशन

org.example.domain - कर्मचारी - कंपनी - EmployeeLevel

org.example.domain.shared - प्रक्रिया - BusinessRule - सत्यापनकर्ता

org.example.infrastructure

उम्मीद है कि, यह छोटा स्निपेट थोड़ा स्पष्टता जोड़ता है।

तो, प्रक्रिया, व्यवसाय नियम, और सत्यापनकर्ता अवधारणाएं डोमेन के अंदर झूठ बोलेंगी, लेकिन सिस्टम की चीजों के संदर्भ में डोमेन मॉडल का समर्थन करेंगे।

Answer 1

विकिपीडिया से:

डोमेन पर ही आधारित डिजाइन (DDD) गहरा मुख्य व्यवसाय अवधारणाओं का बढ़ता मॉडल के कार्यान्वयन को जोड़ने के द्वारा जटिल जरूरतों के लिए सॉफ्टवेयर विकसित करने के लिए एक दृष्टिकोण है।

मेरा मानना ​​है कि वैधकर्ता, प्रक्रिया, नियम आपकी मूल व्यावसायिक अवधारणाएं नहीं हैं। वे बल्कि सामान्य सॉफ्टवेयर abstractions हैं।

मैं "बाय-द-बुक" डीडीडी का बड़ा प्रशंसक नहीं हूं, लेकिन आपके डीएसएल को और अधिक "डोमेन संचालित" होने के लिए और वास्तव में आपके नियमों को और अधिक समझने के लिए आपके व्यवसाय अवधारणाओं के आसपास बनाया जाना चाहिए ।

हुड के तहत, आप अभी भी वैधकर्ताओं, प्रक्रियाओं, प्रबंधकों, निष्पादकों आदि का उपयोग कर सकते हैं, लेकिन यदि आप सॉफ़्टवेयर अवशेषों के बजाए उनमें व्यावसायिक अवधारणाओं का उपयोग करते हैं तो आपके डीएसएल/नियम अधिक पठनीय होंगे।

UPDATED: यदि आप अपने डीएसएल परिभाषित करने के लिए ग्रूवी उपयोग कर रहे हैं के बाद से, आप ग्रूवी की गतिशील विधि नाम को हल करने और बिल्डर कार्यक्षमता का उपयोग पठनीय नियमों और कक्षाएं बनाने के लिए कर सकते हैं। इसके अलावा आप कुछ तर्क में हुक करने के लिए "विन्यास पर सम्मेलन" सिद्धांत का लाभ उठा सकते हैं। जो अपने आप में

if (employee is "promotable") { 
    start "promotion" for employee 
} 

is एक आधार डोमेन वस्तु पर एक विधि है कि मान लें EmployeePromotableValidator वर्ग, के होने की जाँच करेगा हो जाएगा यह भी एक ग्रूवी हो सकता है: उदाहरण के लिए, ग्रूवी में आप के लिए कुछ इसी तरह का निर्माण करने की कोशिश कर सकते हैं कक्षा जो ग्रोवी की डीएसएल अभिव्यक्ति का लाभ उठाती है।

class EmployeePromotableValidator extends Validator<Employee> { 

    boolean validate(Employee employee) { 
    employee.age > 25 && employee.workingYears > 2 
    } 

} 

start अपने आधार नियम स्क्रिप्ट पर एक विधि है कि EmployeePromotionProcess वर्ग के लिए खोज करेंगे, कि फिर से एक ग्रूवी वर्ग हो सकता है किया जाएगा। इस मामले में

विशिष्टता पैटर्न, बहुत सरल है, क्योंकि यह मूल रूप से भाषा का हिस्सा बन जाता:

if (employee is "promotable" && 
    employee is "advanced" && 
    employee.salary < 10000) { 
    start("salary increase", "10%") for employee 
} 

सामान्य तौर पर, के (अर्ध) ग्रूवी/स्काला तरह कार्यात्मक भाषाओं इस्तेमाल किया जा सकता मदद से DSLs सॉफ़्टवेयर abstractions को छिपाने के लिए और कोड में अपने व्यापार तर्क अधिक प्रमुख बनाते हैं। सादे जावा के साथ आप बहुत सारे बॉयलर प्लेट कोड के साथ समाप्त हो जाएंगे जो अंततः आपके सभी इरादे छुपाएगा।

Answer 2

यह इस बात पर निर्भर करता है कि आपका व्यवसाय डोमेन वास्तव में क्या है।

यदि आप बड़े अतिरिक्त कॉन्फ़िगर करने योग्य सीआरएम का निर्माण कर रहे हैं तो कुछ कन्स्ट्रक्टर कुछ सबकुछ कर रहा है - तो आपका व्यवसाय डोमेन इसे संभव बनाने के आसपास है, इसलिए Process, Executors आदि जैसे संज्ञाएं आपके डोमेन का हिस्सा हैं।

यदि आप ऐसे एप्लिकेशन का निर्माण कर रहे हैं जो कर्मचारियों और उनकी प्रचारकता के बारे में जानकारी ट्रैक कर लेता है - तो आपका व्यवसाय डोमेन कर्मचारियों, पेचेक, प्रदर्शन माप के बारे में है। इस मामले में Process, Executors और आपके डोमेन के घुसपैठियों के समान सामानों का इलाज करें।

कुछ स्तर पर - यहां तक ​​कि प्रोग्रामिंग भाषा ही एक आक्रामक उपकरण है जो आपके दिमाग में समस्या का समाधान हल करती है। लेकिन यह आवश्यक है - अन्यथा आप इसे पूरा करने में सक्षम नहीं होंगे।