जब माइक्रोसॉर्विस की बात आती है, तो सेवाओं का विकास जीवन चक्र भी स्वतंत्र होना चाहिए। *
विभिन्न एसएलडीसी और विभिन्न देव टीमें
एक वास्तविक एमएस प्रणाली में, पारिस्थितिकी तंत्र के विकास में कई टीमें शामिल हो सकती हैं, जिनमें से प्रत्येक एक या एक से अधिक सेवाओं का प्रभारी होता है। बदले में, ये टीम विभिन्न कार्यालयों, शहरों, देशों, योजना में स्थित हो सकती है ... शायद, वे एक-दूसरे को भी नहीं जानते हैं, जो ज्ञान या कोड को साझा करना बहुत कठिन बनाता है (यदि संभव हो)। लेकिन यह बहुत सुविधाजनक हो सकता है क्योंकि साझा कोड भी एक तरह का साझा तर्क देता है और याद रखने के लिए कुछ महत्वपूर्ण है, जो कि एक विशिष्ट टीम के लिए समझ में आता है, उसे दूसरी टीम के लिए नहीं बनाना है। उदाहरण के लिए, डीटीओ ग्राहक को देखते हुए , यह खेल में सेवा के आधार पर भिन्न हो सकता है, क्योंकि ग्राहकों को प्रत्येक सेवा से अलग तरीके से व्याख्या (या देखी) जाती है।
विभिन्न आवश्यकताओं, विभिन्न प्रौद्योगिकियों
पृथक SLDCs भी टीमों को स्टैक का चयन करने की अनुमति देता है जो उनकी आवश्यकताओं के अनुसार सबसे अच्छा है। किसी विशिष्ट तकनीक में कार्यान्वित डीटीओ को चुनना टीमों की चुनने की क्षमता को सीमित करता है।
डीटीओ न तो व्यावसायिक नियम हैं और न ही सेवा अनुबंध
डीटीओ वास्तव में क्या हैं? एक तरफ से दूसरी ओर जाने वाले डेटा की तुलना में कोई अन्य लक्ष्य नहीं है। गेटर्स और सेटर का बैग। यह "ज्ञान" की तरह नहीं है जो पुन: उपयोग के लायक है, कुल मिलाकर क्योंकि वहाँ बिल्कुल भी ज्ञान नहीं है। उनकी अस्थिरता उन्हें युग्मन के लिए बुरा उम्मीदवार भी बनाती है।
धेरिक ने जो कहा है, उसके विपरीत, एक सेवा के लिए अपने डीटीओ को बदलने के लिए संभव होना चाहिए बिना एक ही समय में अन्य सेवाओं को बदलने के लिए। सेवाएं चाहिए होना सहिष्णु पाठकों, सहिष्णु लेखकों और असफल सहिष्णु । अन्यथा, वे इस तरह से युग्मन का कारण बनते हैं जो सेवा वास्तुकला को कोई मतलब नहीं देता है। एक बार और, और धरिक के जवाब के विपरीत, यदि तीन सेवाओं को बिल्कुल एक ही डीटीओ की आवश्यकता है, तो संभावना है कि सेवाओं के अपघटन के दौरान कुछ गलत हो गया था।
विभिन्न व्यवसाय, विभिन्न व्याख्याएं
हालांकि, सेवाओं के बीच क्रॉस-कटिंग अवधारणाएं हो सकती हैं (इसका मतलब यह नहीं है कि हमें सभी सेवाओं को उसी तरह व्याख्या करने के लिए मजबूर करने के लिए एक विहित मॉडल लागू करना होगा।
मामले का अध्ययन
मान लें कि हमारी कंपनी के तीन विभाग हैं, ग्राहक सेवा , बिक्री और शिपिंग । कहते हैं कि इनमें से प्रत्येक एक या अधिक सेवाएं जारी करता है।
ग्राहक सेवा, अपनी डोमेन भाषा के कारण, ग्राहकों की अवधारणा के आसपास सेवाओं को लागू करती है, जहाँ ग्राहक व्यक्ति होते हैं । उदाहरण के लिए, ग्राहकों को नाम , अंतिम नाम , आयु , लिंग , ईमेल , फोन आदि के रूप में मॉडल किया जाता है ।
अब कहते हैं, सेल्स और शिपिंग उनकी सेवाओं को उनके संबंधित डोमेन भाषाओं के अनुसार मॉडल करते हैं। इन भाषाओं में, अवधारणा ग्राहक बहुत ही सूक्ष्म अंतर के साथ प्रकट होता है। उनके लिए, ग्राहक (आवश्यक) व्यक्ति नहीं हैं । के लिए बिक्री , ग्राहकों को एक कर रहे हैं दस्तावेज़ संख्या एक क्रेडिट कार्ड और एक बिलिंग पता , के लिए शिपिंग एक पूरा नाम और एक शिपिंग पता भी।
यदि हम बिक्री और शिपिंग को ग्राहक सेवा के विहित डेटा मॉडल को अपनाने के लिए मजबूर करते हैं, तो हम उन्हें अनावश्यक डेटा से निपटने के लिए मजबूर कर रहे हैं जो अनावश्यक जटिलता को शुरू कर सकता है अगर उन्हें पूरे प्रतिनिधित्व को बनाए रखना है और ग्राहक डेटा को ग्राहक सेवा के साथ समन्वय में रखना है। ।
सम्बंधित लिंक्स
* यहाँ है जहाँ इस वास्तुकला की ताकत पर देता है
protoजीआरपीसी के लिए फ़ाइल याavroकाफ्का के लिए स्कीमा और दोनों सेवाओं में डीटीओ को उत्पन्न करना ठीक है, लेकिन मैं दो परियोजनाओं के बीच एक साझा पुस्तकालय साझा नहीं करूंगा।