मेरी परियोजना में, मेरे पास वर्कफ़्लो है जो एक व्यापार लेनदेन को पूरा करने के लिए कई इकाइयों पर काम करता है। वर्कफ़्लो तर्क का प्रतिनिधित्व करने के लिए सबसे अच्छी जगह क्या है? वर्तमान में मैं सिर्फ एक "XXX प्रबंधक" बना रहा हूं जो एक व्यापार लेनदेन को समाप्त करने के लिए इकाई वस्तुओं के साथ सहयोग करने के लिए ज़िम्मेदार है। क्या अन्य विकल्प हैं?डोमेन संचालित डिजाइन: वर्कफ़्लो तर्क कहां स्थित है?
डीडीडी इस तरह की चीज के बारे में बिल्कुल नहीं हो सकता है, इसलिए मैं सेवा परत वास्तुशिल्प पैटर्न को देखने का सुझाव दूंगा। मार्टिन फाउलर की पुस्तक पैटर्न ऑफ़ एंटरप्राइज़ आर्किटेक्चर एक अच्छी किताब है जो इसे समझाएगी। आप फाउलर की वेबसाइट पर पैटर्न के विवरण भी पा सकते हैं।
वर्कफ़्लो सिस्टम बनाना एक कठिन संभावना हो सकती है। क्या आपने Workflow engines का उपयोग करने पर विचार किया है?
यदि मैं आपको सही ढंग से समझता हूं, तो आपको एक प्रबंधक बनाना होगा जो उपयोगकर्ता से संबंधित वर्कफ़्लो में विभिन्न लेन-देन का ट्रैक रखता है। ऐसा करने के अन्य तरीके हैं - लेकिन मैंने हमेशा इंजन का उपयोग किया है।
आमतौर पर एक डोमेन ऑब्जेक्ट होता है जो वास्तव में उस नियंत्रण को नियंत्रित करता है जो "इकाई" के लिए गलत है।
क्या इस वर्कफ़्लो के परिणामस्वरूप कुछ ऐसा उत्पन्न हुआ है? यदि ऐसा है, वर्कफ़्लो तर्क शायद वहां पर है। नीचे दिए गए मॉडल में "ऑर्डर" पर विचार करें।
alt text http://img685.imageshack.us/img685/4383/order.png
ओडर दोनों एक संज्ञा और एक क्रिया है। "ऑर्डर" ऑब्जेक्ट है जो "ऑर्डरिंग" के परिणामस्वरूप बनाया गया है। किसी भी अच्छी कक्षा की तरह, इसमें डेटा और व्यवहार दोनों होते हैं (और मेरा मतलब गेटर्स और सेटर्स नहीं है)। व्यवहार गतिशील प्रक्रिया है जो डेटा के साथ जाती है, यानी ऑर्डरिंग वर्कफ़्लो। "ऑर्डर" नियंत्रक है।
यही कारण है कि ओओ का आविष्कार किया गया था।
मैं कहूंगा कि आप कुछ करने के लिए कई इकाइयों के साथ सहयोग करने के लिए सही काम कर रहे हैं। महत्वपूर्ण बात यह है कि प्रत्येक इकाई (और वास्तव में प्रत्येक सेवा) में single responsibility होना चाहिए।
आप जिस वर्कफ़्लो के बारे में बात कर रहे हैं वह कुछ ऐसा है जिसे आप अपने एप्लिकेशन लेयर के हिस्से के रूप में देख सकते हैं।
According to Paul Gielens (पैराफ्रेशेड) आवेदन परत की ज़िम्मेदारी पाठ्यक्रम-दाग अनुरोध (संदेश/आदेश) को एक निश्चित अतिव्यापी लक्ष्य को प्राप्त करने के लिए पचाना है। यह पूर्ति के लिए डोमेन सेवाओं को एक संदेश भेजकर ऐसा करता है। इसके बाद यह (वैकल्पिक रूप से) इंफ्रास्ट्रक्चर सेवा को अधिसूचनाएं भेजने का फैसला करता है।
लेकिन फिर 'सेवा' क्या है ?! यह एक अतिभारित अवधि है, लेकिन एक है कि अच्छी तरह से वर्णित है (फिर से, by Paul Gielens)
तुम भी अधिक विचारों के लिए के बारे में Onion Architecture भी पढ़ सकते हैं ...
टीएक्सएन, दिलचस्प लेख! –
, मैं "domain events" (लिंक जोड़ना चाहते हैं सिर्फ एक संभावित कार्यान्वयन के लिए है) जो कुछ इवान्स स्वयं ("increased emphasis on events") पर अधिक ध्यान देने आया है।
कोई कह सकता है कि ओओ डोमेन मॉडलिंग क्रियाओं के संज्ञाीकरण के बारे में है। प्याज आर्किटेक्चर संदर्भ के लिए –