👐🏿 ➕ 🦂 एक बंधे हुए संदर्भ कैनवस के साथ एक बंधे हुए संदर्भ को डिजाइन करना: कार्यशाला नुस्खा 🙋🏿 🎭 ☑️

आगामी TechLead Conf 2020 सम्मेलन के विषयों के बीच डोमेन-चालित डिजाइन और EventStorming की विस्तृत चर्चा होगी। डीडीडी पर कोंस्टेंटिन गुस्टोव द्वारा 2-स्लॉट रिपोर्ट तैयार करने के अलावा , ईवेंटस्टॉर्मिंग पर सर्गेई बारानोव की एक रिपोर्ट, और एक म्यूटैप जिसके दौरान हम एक डीडीडी रडार बनाएंगे, हमने एक लेख का अनुवाद करने का फैसला किया है जो बाध्य संदर्भ को डिजाइन करने के लिए सबसे लोकप्रिय तरीकों में से एक है।

बड़ी प्रणाली को छोटे, अधिक प्रबंधनीय घटकों में कैसे तोड़ा जाए? मुझसे अक्सर यह सवाल पूछा जाता है, इसलिए मैंने इस लेख में अपना ज्ञान एकत्र किया।

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

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

“मैंने सार्वजनिक आयोजनों और कॉर्पोरेट सत्रों में DDD कार्यशालाएँ करने की प्रक्रिया में इस कैनवास को विकसित किया है। यदि आप ऐसे प्रारूप पाते हैं जो आपके लिए सबसे उपयुक्त हैं, तो इसकी संरचना को बदलने के लिए स्वतंत्र महसूस करें। ”

विधि

मुख्य नुस्खा में निम्नलिखित शामिल हैं:

EventStorming (न्यूनतम 1 घंटा)।
एक बंधे हुए संदर्भ (न्यूनतम 30 मिनट) के लिए मॉडलिंग के उम्मीदवार।
डोमेन संदेशों का प्रवाह मॉडलिंग (कम से कम 30 मिनट)।
बँधा हुआ प्रसंग कैनवस (न्यूनतम 90 मिनट)।
प्रासंगिक मानचित्र बनाना (कम से कम 45 मिनट)।

एक शुरुआती बिंदु के रूप में, मैं इस कार्यशाला के लिए एक पूरा दिन आवंटित करने की सलाह देता हूं। यह आपको यह समझने में मदद करेगा कि कार्यशाला को सही ढंग से संचालित करने के लिए आपको वास्तव में कितना समय चाहिए। यदि सभी को एक साथ इकट्ठा करना महंगा (समय लेने वाला) है, तो सब कुछ करने के लिए तुरंत दो दिन आवंटित करने का प्रयास करें।

आदर्श रूप से, प्रतिभागियों को विषय विशेषज्ञ और तकनीकी विशेषज्ञ होना चाहिए। यदि यह व्यवस्थित करना मुश्किल है, तो यह सुनिश्चित करने का प्रयास करें कि डोमेन विशेषज्ञ कम से कम पहले घंटे के लिए कार्यशाला में हैं।

मॉडलिंग के मूल सिद्धांत

विशेषज्ञों के साथ एक सत्र आयोजित करने के लिए, आपको एक विशाल कमरे की आवश्यकता है। यदि आप एक छोटा श्रोता चुनते हैं, तो आप परिणामों से निराश होंगे। 4 लोगों के प्रत्येक समूह को दीवार पर कम से कम 4 मीटर की आवश्यकता होगी।

मैं सख्त नियमों के बिना, स्वतंत्र रूप में अपनी कार्यप्रणाली का वर्णन करूंगा। हालाँकि, ध्यान रखें:

“हम लगातार समस्या स्थान और समाधान स्थान के बीच स्विच कर रहे हैं। "हम जानकारी की तलाश कर रहे हैं, एक मॉडल बना रहे हैं, अतिरिक्त जानकारी की तलाश कर रहे हैं, मॉडल को अपडेट कर रहे हैं, आदि।"

और एक और महत्वपूर्ण बिंदु: सत्र का उद्देश्य भविष्य में बेहतर विकल्पों की पेशकश करने की क्षमता विकसित करना और विकसित करना है।

1. EventStorming

एक प्रणाली को डिजाइन करने के लिए, आपको दो चीजों की आवश्यकता है: पूरे सिस्टम का एक अच्छा पर्याप्त सामान्य विचार और प्रत्येक क्षेत्र में विवरणों की काफी गहरी समझ। ऐसा करने के लिए, चलिए EventStorming से शुरू करते हैं ।

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

यदि ऐसा करने का यह आपका पहला अवसर है, तो मेरा सुझाव है कि आप EventStorming पर 1-2 घंटे अलग रखें। EventStorming पूरा करने के बाद, मैं 4 लोगों के समूह में विभाजित होने की सलाह देता हूं।

TechLead Conf 2020 में, Sergey Baranov EventStorming के साथ व्यावहारिक अनुभव के बारे में बात करेंगे ।

2. बाध्य संदर्भ के लिए उम्मीदवारों की खोज करें

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

बंधे हुए संदर्भ को निर्धारित करने के लिए कई तरीके हैं। मैं निम्नलिखित के साथ शुरू करने की सलाह देता हूं:

मूल्य से शुरू करें - डोमेन के मुख्य भागों की पहचान करें जो व्यवसाय के लिए सबसे अधिक मूल्यवान हैं।
एक सरल के साथ शुरू करें - समय-समय पर क्रमिक चरणों को तोड़कर एक भोली मॉडल बनाएं।
प्रमुख घटनाओं की तलाश करें - व्यवसाय की घटनाएं जो व्यवसाय प्रक्रिया के विभिन्न हिस्सों को प्रभावित करती हैं।

पहली बार, इस कार्य पर 30 मिनट से अधिक नहीं खर्च करें। प्रारंभिक बिंदु के रूप में मूल बंधे हुए संदर्भ मॉडल बनाने के लिए समूह को आमंत्रित करें। यह सही नहीं है और अंतिम समाधान होने की संभावना नहीं है।

आउटपुट एक फ्लिपकार्ट या पेपर पर बंधे हुए संदर्भ नामों की सूची में होना चाहिए। यदि आपके पास कई समूह हैं, तो आप EventStorming को भौतिक रूप से संशोधित नहीं कर सकते।

अगला कदम

आप सिस्टम को मॉडल करने के कई तरीके देख सकते हैं। अभी के लिए, उनमें से एक को काम के लिए चुनें और अन्य संभावित मॉडलों को लिखें (वे बाद में उपयोगी होंगे)। आप यह भी समझ सकते हैं कि आपको डोमेन जानकारी याद आ रही है। यदि हां, तो EventStorming का एक और दौर करें।

3. मॉडलिंग डोमेन संदेश प्रवाह

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

यदि बड़ी संख्या में निर्भरता और द्वि-दिशात्मक कनेक्शन के साथ, डोमेन स्ट्रीम जटिल हो गई, तो आपका डिज़ाइन नाजुक है और आगे के विश्लेषण की आवश्यकता है।

ऐसे कई विज़ुअलाइज़ेशन मेथड हैं जिनका उपयोग यूएमएल सीक्वेंस डायग्राम और यूएमएल यूसेज केस डायग्राम सहित मॉडल फ़्लो और केस के उपयोग के लिए किया जा सकता है। मैं डोमेन कहानी कहने के विकल्प का उपयोग करने की सलाह देता हूं ।

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

एक डोमेन संदेश प्रवाह का एक काल्पनिक उदाहरण

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

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

अगला कदम

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

4. बंधे हुए कनैक्ट्स कैनवस

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

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

4.1 सामान्य संदर्भ की परिभाषा

अपने बंधे हुए संदर्भ के नाम और उसके विवरण को परिभाषित करके शुरू करें। विवरण को डोमेन में संदर्भ का उद्देश्य और व्यवसाय में इसकी भूमिका दर्शानी चाहिए, न कि कार्यान्वयन विवरण।

अगला, आपको एक रणनीतिक वर्गीकरण बनाने की आवश्यकता है। बाध्य संदर्भ प्रणाली के मुख्य भाग, एक सहायक तत्व, एक सामान्य एक या कुछ और है? अगर आपको मदद की ज़रूरत है तो व्लाद का पोस्ट पढ़ें ।

एक उदाहरण के रूप में, 1 चरण से गुजरने के बाद एक भरा हुआ बंधे हुए कैनवस।

अगला कदम

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

४.२ व्यावसायिक नियमों का स्पष्टीकरण और एक सामान्य भाषा का निर्माण

अब EventStorming पर वापस जाएं और इस बंधे हुए संदर्भ के लिए नोट देखें। सबसे महत्वपूर्ण व्यावसायिक नियमों और नीतियों को ढूंढें, फिर 3 सबसे महत्वपूर्ण का चयन करने और उन्हें कैनवास में जोड़ने का प्रयास करें।

TechLead Conf 2020 में Konstantin Gustov , Raiffeisen में Ubiquitous Language और अन्य DDD घटकों के साथ काम करने के अपने कई वर्षों के अनुभव के बारे में बात करेंगे ।

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

4.3 फ़ीचर विश्लेषण

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

क्या यह संदर्भ जिम्मेदारियों से भरा हुआ है?
क्या अवसर संबंधित दिखते हैं?
क्या क्षमताएं संदर्भ के नाम और विवरण से मेल खाती हैं?
अगर हम इस अवसर को संदर्भ से बाहर ले जाएं तो क्या होगा?

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

सभी सुविधाएँ बाहर से आदेशों और अनुरोधों द्वारा सक्रिय नहीं की जाती हैं। कुछ सुविधाओं को भीतर से लॉन्च किया जा सकता है। उदाहरण के लिए, अनुसूचित कार्य। कभी-कभी आप नोटिस कर सकते हैं कि अवसरों का क्लस्टर किया गया है, उदाहरण के लिए, एक कमांड, अनुरोध, और अधिसूचना। यदि ऐसा है, तो उन्हें कैनवास पर एक साथ रखें और क्लस्टर को एक नाम दें।

आपको यह महसूस हो सकता है कि जिम्मेदारी अनुचित है और इसे किसी अन्य बाध्य संदर्भ से संबंधित होना चाहिए। यदि ऐसा है, तो स्टिकर पर किसी प्रकार के पहचान चिह्न के साथ इसका चयन करें।

अगला कदम

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

गहरा करने की क्षमता [वैकल्पिक]

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

4.4 निर्भरता

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

EventStorming परिणाम और डोमेन प्रवाह आरेख के माध्यम से देखते हुए, प्रत्येक निर्भरता की पहचान करें जिसका एक बाध्य संदर्भ है और निम्नलिखित जानकारी लिखें:

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

प्रत्येक निर्भरता पर प्रश्न: क्या इसकी आवश्यकता है, इसकी उपलब्धता की लागत और लाभ क्या हैं। यदि ऐसा लगता है कि आप इसके बिना कर सकते हैं, तो पीले स्टिकर के साथ निर्भरता को चिह्नित करें।

४.५ रचनात्मक आलोचना

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

अच्छा : डिजाइन पहलुओं जो आपको पसंद हैं।
खराब : डिजाइन के ऐसे पहलू जो आपको पसंद नहीं हैं।
Unsure : ऐसे डिज़ाइन पहलू जो आप निश्चित नहीं हैं।

4.6। प्रतिबिंब और दोहराव

अच्छा डिजाइन पुनरावृत्त है। अगले बंधे संदर्भ पर आगे बढ़ने से पहले, पीछे हटें और बड़ी तस्वीर देखें। क्या आपने कुछ भी सीखा है जो आपके डिजाइन के विपरीत है? यदि ऐसा है, तो प्रस्तावित सीमाओं को पार करें, और फिर अगले बाध्य संदर्भ को डिज़ाइन करना जारी रखें।

इस बिंदु पर, अपने आप से पूछें कि क्या डोमेन पर्याप्त विवरण में मॉडल किया गया है। क्या कैनवास के कुछ हिस्सों को भरना मुश्किल था? यदि ऐसा है, तो पूरे डोमेन या इसके कुछ हिस्सों में EventStorming के एक और दौर का प्रयास करें।

5. संदर्भ मानचित्र बनाना

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

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

बहुत सटीक संदर्भ मानचित्र का एक उदाहरण, इस कार्यशाला के लिए यह पर्याप्त है।

हम TechLead Conf 2020 में एक बैठक करेंगे, जहाँ हम DDD की विभिन्न तकनीकों, प्रतिमानों और प्रतिमानों का विश्लेषण करेंगे और एक विज़ुअल रडार एकत्र करेंगे। जिसे सम्मेलन के बाद प्रकाशित किया जाएगा।

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

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

यदि आप इन परिवर्तनों की कल्पना करना पसंद करते हैं, तो निम्न चित्र उपयोगी हो सकते हैं:

कार्यशाला का समापन

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

प्रस्तुति में आपको क्या विचार करने की आवश्यकता है:

: .
: .
, , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

एक बंधे हुए संदर्भ कैनवस के साथ एक बंधे हुए संदर्भ को डिजाइन करना: कार्यशाला नुस्खा

विधि

मॉडलिंग के मूल सिद्धांत

1. EventStorming

2. बाध्य संदर्भ के लिए उम्मीदवारों की खोज करें

अगला कदम

3. मॉडलिंग डोमेन संदेश प्रवाह

अगला कदम

4. बंधे हुए कनैक्ट्स कैनवस

4.1 सामान्य संदर्भ की परिभाषा

अगला कदम

४.२ व्यावसायिक नियमों का स्पष्टीकरण और एक सामान्य भाषा का निर्माण

4.3 फ़ीचर विश्लेषण

अगला कदम

गहरा करने की क्षमता [वैकल्पिक]

4.4 निर्भरता

४.५ रचनात्मक आलोचना

4.6। प्रतिबिंब और दोहराव

5. संदर्भ मानचित्र बनाना

कार्यशाला का समापन

More articles: