डोमेन-संचालित डिज़ाइन: एक व्यावहारिक विशेषज्ञ के लिए एक नुस्खा

डीडीडी आमतौर पर गलत साइड से क्यों आते हैं? और आप किस पक्ष को चाहते हैं? जिराफ और प्लैटिपस को इस सब से क्या लेना देना है?

विशेष रूप से हैबर के लिए - रिपोर्ट का एक पाठ प्रतिलेख "डोमेन-संचालित डिजाइन: एक व्यावहारिक के लिए एक नुस्खा।" रिपोर्ट DotNext .NET सम्मेलन में बनाई गई थी, लेकिन यह न केवल दाताओं के लिए उपयोगी हो सकती है, बल्कि उन सभी के लिए भी है जो DDD में रुचि रखते हैं (हमें विश्वास है कि आप C # कोड उदाहरणों के एक जोड़े को मास्टर करेंगे)। रिपोर्ट की एक वीडियो रिकॉर्डिंग भी संलग्न है।



सभी को मेरा नमस्कार, मेरा नाम एलेक्सी मर्सन है। मैं आपको बताऊंगा कि Domain-Driven Design क्या है और इसका सार क्या है, लेकिन सबसे पहले, आइए जानें कि इसकी आवश्यकता क्यों है।



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

पहली नज़र में, वास्तव में कोई तर्क नहीं है। लेकिन यह प्राचीन मछली से बची हुई एक घनी विरासत है। मछली में, जैसा कि आप जानते हैं, कोई गर्दन नहीं है, इसलिए यह तंत्रिका इष्टतम पथ के साथ चलती है। और जब स्तनधारियों के कई मिलियन वर्षों के बाद रिफ्लेक्टिंग के बाद दिखाई दिया, तो तंत्रिका को पिछड़ेपन को बनाए रखने के लिए बढ़ाया जाना था। खैर, कुछ जिराफ की वजह से फिर से तैयार न करें?

लेकिन जिराफ ठीक है, क्योंकि एक प्लैटिपस है।


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

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

मुझे पता है कि अब आप क्या सोच रहे हैं: "अलेक्सी, ठीक है, आपने हमसे डोमेन-संचालित डिज़ाइन का वादा किया है, और यहाँ" जानवरों की दुनिया में "कुछ इस तरह का है!"

सहकर्मी, विकास क्या है? विकास तब होता है जब हम वास्तविक दुनिया का कुछ हिस्सा, एक व्यावसायिक प्रक्रिया लेते हैं, और इसे कोड में बदलते हैं, अर्थात एक सॉफ्टवेयर मॉडल बनाते हैं। रास्ते में किन समस्याओं का हमें इंतजार है?

पहला स्वयं व्यवसाय प्रक्रियाओं की जटिलता है, अर्थात यह समझने में कठिनाई होती है कि व्यवसाय कैसे काम करता है, वहां कौन सी प्रक्रियाएं हो रही हैं, वे किस तर्क से निर्मित हैं।

दूसरी समस्या कोड के रूप में इन व्यावसायिक प्रक्रियाओं के कार्यान्वयन, सही पैटर्न का उपयोग, सही दृष्टिकोण, और इसी तरह है। यह भी एक जटिल विषय है।

देखो, व्यवसाय प्रक्रियाएं उस जिराफ़ की तरह हैं: उन्होंने सबसे सरल एककोशिकीय लोगों के साथ शुरुआत की, और फिर "यह" आपको देखता है, और कोई भी यह नहीं समझता है कि "यह कहाँ से आया" या "यह कैसे काम करता है"।

ऐसी प्रक्रिया के सफल मॉडल का निर्माण करने के लिए, आपको पहले प्रश्न "क्यों?" का उत्तर देना होगा। हम इस मॉडल का निर्माण क्यों करना चाहते हैं? हम किन लक्ष्यों को प्राप्त करना चाहते हैं? आखिरकार, यदि ग्राहक एक जिराफ भरवां चाहता था, लेकिन हिम्मत मिली, तो वह परेशान हो जाएगा, भले ही इस मॉडल में पाचन आंखों की खातिर लागू हो। और ग्राहक न केवल पैसा और समय खो देगा, वह डेवलपर्स के रूप में हम पर विश्वास खो देगा, और हम अपनी प्रतिष्ठा और ग्राहक खो देंगे।

लेकिन अगर हम लक्ष्यों का पता लगा लेते हैं, तब भी यह गारंटी नहीं देता है कि परिणामस्वरूप हमें प्लैटिपस नहीं मिलेगा। तथ्य यह है कि लक्ष्य को समझना बहुत कम है। लक्ष्य प्राप्त करना होगा। और इससे हमें Domain-Driven Design में मदद मिलती है।

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

Domain-Driven Design में कई चीजें शामिल हैं। यह रणनीतिक डिजाइन, और लोगों के बीच बातचीत, और वास्तुकला, और सामरिक पैटर्न के लिए दृष्टिकोण - यह एक संपूर्ण शस्त्रागार है जो वास्तव में काम करता है और वास्तव में परियोजनाओं को बनाने में मदद करता है। केवल एक "लेकिन" है। इससे पहले कि आप डोमेन-संचालित डिज़ाइन के साथ जटिलता से निपटना शुरू करें, आपको यह सीखना होगा कि डोमेन-डिज़ाइन डिज़ाइन की जटिलता से कैसे निपटें।



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

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

दाईं ओर यदि आप कंपाइलर पर सामरिक पैटर्न फेंकते हैं तो क्या होता है। वाम - यदि आप रणनीतिक पैटर्न का उपयोग करते हैं।



ब्लू बुक के विमोचन के बाद से, बल्कि एक मजबूत डीडीडी समुदाय का गठन किया गया है, कई चीजों पर पुनर्विचार किया गया है। हां, और इवांस ने खुद स्वीकार किया कि वह अब यह नहीं समझते हैं कि रणनीतिक डिजाइन के रूप में वह इतनी महत्वपूर्ण चीज को कैसे समाप्त कर सकते हैं।

और 10 साल बाद, 2013 में, रेड बुक को वॉन वर्नोन द्वारा प्रकाशित किया गया था। और इस पुस्तक में, प्रस्तुतिकरण पहले से ही सही क्रम में बनाया गया है: यह रणनीतिक डिजाइन के साथ शुरू होता है, मूल बातें के साथ। और जब पाठक को आवश्यक आधार मिला है, तो वे पहले से ही सामरिक पैटर्न और कार्यान्वयन विवरण के बारे में बात करना शुरू कर देते हैं।

आमतौर पर डीडीडी पर रिपोर्टों में वे इवांस को पढ़ने की सलाह देते हैं, इंटरनेट पर यहां तक ​​कि पूरे मैनुअल हैं जिसमें आपको उचित विसर्जन के लिए अध्याय पढ़ने की आवश्यकता होती है। मैं इसे आसान करने की सलाह देता हूं: रेड बुक से शुरू करें, इसे पढ़ें, और उसके बाद ही ब्लू पर जाएं।

और चूंकि रणनीतिक डिजाइन इतनी महत्वपूर्ण बात है, तो आइए इसके प्रमुख विचारों के बारे में बात करते हैं।

"रणनीतिक डिजाइन के मुख्य विचार"

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



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

ऐसा क्यों हो रहा है? क्योंकि विशिष्ट परिस्थिति में तकनीकी विशेषज्ञों और डोमेन विशेषज्ञों के बीच की बातचीत कुछ इस तरह दिखाई देती है: उनके बीच एक बड़ी-बड़ी दीवार होती है, और एक प्रबंधक इस दीवार के शीर्ष पर चलता है और सबसे पहले यह सुनने की कोशिश करता है कि वे दीवार के एक तरफ क्या चिल्ला रहे हैं, तो वह इसे स्नायुबंधन के सबसे अच्छे से चिल्लाने की कोशिश करता है। दीवार के दूसरी तरफ, और इसी तरह एक सर्कल में।

कभी-कभी एक प्रबंधक बहरा होता है, तो ऐसे प्रबंधकों की एक पूरी श्रृंखला बनाई जा सकती है, जो निश्चित रूप से परियोजना की सफलता में योगदान नहीं करते हैं। और यह कैसा होना चाहिए?



निरंतर बातचीत होनी चाहिए। तकनीकी विशेषज्ञ, डोमेन विशेषज्ञ - सभी परियोजना प्रतिभागियों को संचार को बनाए रखना, सिंक्रनाइज़ करना, लक्ष्यों पर चर्चा करना, उन्हें प्राप्त करने के तरीके, और हम यह सब क्यों करते हैं।

और यहाँ हम रणनीतिक डिजाइन और डोमेन-चालित डिजाइन दोनों का सबसे महत्वपूर्ण मुख्य बिंदु हैं।



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

व्यावसायिक परिदृश्य

आगे की चर्चा के लिए, हमें किसी प्रकार के व्यावसायिक परिदृश्य की आवश्यकता है। आइए इस स्थिति की कल्पना करें:



JUG.ru समूह के निदेशक हमारे पास आते हैं और कहते हैं: "दोस्तों, रिपोर्ट का प्रवाह बढ़ रहा है, लोग, सामान्य रूप से, सब कुछ मैन्युअल रूप से करने के लिए अत्याचार करते हैं ... चलो सम्मेलन की तैयारी की प्रक्रिया को स्वचालित करते हैं।" हम जवाब देते हैं: "ठीक है!" - और काम पर लग जाओ।

पहला परिदृश्य जिसे हम स्वचालित करेंगे: "वक्ता एक विशिष्ट घटना पर एक रिपोर्ट के लिए एक आवेदन प्रस्तुत करता है और इस रिपोर्ट के बारे में जानकारी जोड़ता है।" इस परिदृश्य में हम क्या देखते हैं? एक स्पीकर क्या है, एक घटना है, और एक रिपोर्ट है, जिसका अर्थ है कि पहले डोमेन मॉडल का निर्माण करना पहले से ही संभव है।



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



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

यदि वे "उपयोगकर्ता" कहते हैं, तो सब कुछ एक बार में स्पष्ट होना चाहिए, इसमें एक समझने योग्य भूमिका होनी चाहिए, एक समझने योग्य अर्थ, यह आईटी उद्योग के दृष्टिकोण से किसी प्रकार का सार उपयोगकर्ता नहीं होना चाहिए।



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

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

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

डेमो: बिक्री सेवा

आइए शुष्क सिद्धांत से थोड़ा हटकर कोड देखें।

एक सम्मेलन न केवल सामग्री की तैयारी है, बल्कि बिक्री भी है। आइए कल्पना करें कि टिकट बेचने की एक सेवा पहले ही लिखी जा चुकी है, और एक बिक्री प्रबंधक हमारे पास आता है और कहता है: “दोस्तों! एक बार जब किसी ने इस सेवा को लिखा, तो इसे समझ लें, मेरे लिए कुछ भी स्पष्ट नहीं है कि नियमित ग्राहकों के लिए छूट कैसे मानी जाती है। "

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

अब हम जिस कोड का विश्लेषण करेंगे, उसे रिपॉजिटरी में अलग से देखा जा सकता है ।

समाधान खोलें, संरचना को देखें:



ऐसा लगता है कि सब कुछ अच्छा लग रहा है: एप्लिकेशन और कोर है (जाहिरा तौर पर, लोग परतों के बारे में जानते हैं), रिपॉजिटरी ... जाहिर है, व्यक्ति ने इवांस के पहले छमाही में महारत हासिल की थी।

OpenCheckoutService खोलें। हम वहां क्या देखते हैं? यहाँ कोड है :

public void Checkout(long id) { var ord = _ordersRepository.GetOrder(id); var orders = _ordersRepository.GetOrders() .Count(o => o.CustomerId == ord.CustomerId && o.StateId == 3 && o.OrderDate >= DateTime.UtcNow.AddYears(-3)); ord.Price *= (100 - (orders >= 5 ? 30m : orders >= 3 ? 20m : orders >= 1 ? 10m : 0)) / 100; ord.StateId = 1; _ordersRepository.SaveOrder(ord); } 

हम मूल्य के साथ लाइन को देखते हैं: यहां मूल्य में परिवर्तन होता है। हम अपने बिक्री प्रबंधक को बुलाते हैं और कहते हैं: "यहाँ, संक्षेप में, छूट को यहाँ माना जाता है, सब कुछ स्पष्ट है":

 ord.Price *= (100 - (orders >= 5 ? 30m : orders >= 3 ? 20m : orders >= 1 ? 10m : 0)) / 100; 

वह अपने कंधे पर दिखता है: “ओह! तो यह वही है जो ब्रेनफैक जैसा दिखता है! और उन्होंने मुझे बताया कि लोग C # में लिख रहे हैं।

जाहिर है, इस कोड के डेवलपर ने एल्गोरिदम और डेटा संरचनाओं के बारे में एक साक्षात्कार में अच्छी प्रतिक्रिया दी। मैंने स्कूल ओलंपियाड में उसी शैली के बारे में लिखा था। कुछ समय बाद, प्रारूपण और अश्लील रीफ़ैक्टरिंग का उपयोग करते हुए, हम यह पता लगाते हैं कि हमारे लॉन्ग-पीड़ित सेल्स मैनेजर को क्या और क्या समझाया गया है, तर्क यह है कि यदि पिछले 3 वर्षों में किसी व्यक्ति के ऑर्डर की संख्या कम से कम एक है, तो उसे 10% छूट मिलती है , तीन से कम नहीं - 20%, और पांच से कम नहीं - 30%। वह हर्षित छोड़ देता है - अब यह स्पष्ट है कि यह सब कैसे काम करता है।

मुझे लगता है कि कई लोगों ने बॉब मार्टिन का क्लीन कोड पढ़ा है। वहां वह बॉय स्काउट नियम के बारे में कहते हैं: "पार्किंग की जगह जब हम छोड़ते हैं, तो हमें वहां जाने से पहले उसे साफ करना चाहिए।" इसलिए, आइए इस कोड को रिफ्लेक्टर करें ताकि यह मानव दिखे और जो हमने सर्वव्यापी भाषा के बारे में पहले बात की और कोड में इसके उपयोग से मेल खाता है।

यहाँ पर रिफलेक्टेड कोड है।

  public class DiscountCalculator { private readonly IOrdersRepository _ordersRepository; public DiscountCalculator(IOrdersRepository ordersRepository) { _ordersRepository = ordersRepository; } public decimal CalculateDiscountBy(long customerId) { var completedOrdersCount = _ordersRepository.GetLast3YearsCompletedOrdersCountFor(customerId); return DiscountBy(completedOrdersCount); } private decimal DiscountBy(int completedOrdersCount) { if (completedOrdersCount >= 5) return 30; if (completedOrdersCount >= 3) return 20; if (completedOrdersCount >= 1) return 10; return 0; } } 

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

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

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

 public void CheckoutV2(long orderId) { var order = _ordersRepository.GetOrder(orderId); var discount = _discountCalculator.CalculateDiscountBy(order.CustomerId); order.ApplyDiscount(discount); order.State = OrderState.AwaitingPayment; _ordersRepository.SaveOrder(order); } 

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

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



यह तीसरा मुख्य बिंदु है।

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



डोमेन एक वैश्विक चीज है, यह एक वैश्विक विषय क्षेत्र है जिसमें यह विशेष व्यवसाय पैसा कमाता है। उदाहरण के लिए, DotNext के लिए यह एक सम्मेलन है, Pyaterochka के लिए यह माल की खुदरा बिक्री है।

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

फिर भी, यह कुछ वैश्विक है और इसे सीधे स्वचालित नहीं किया जा सकता है, यहां तक ​​कि इसकी जांच करना भी मुश्किल है। विश्लेषण के लिए, डोमेन अनिवार्य रूप से उप-डोमेन में, यानी उप-डोमेन में विभाजित है।



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

उदाहरण के लिए, यदि हम एक ऑनलाइन स्टोर लेते हैं, तो यह ऑर्डर का गठन और प्रसंस्करण होगा, यह वितरण होगा, यह आपूर्तिकर्ताओं के साथ काम करता है, यह मार्केटिंग है, यह लेखांकन है। यहाँ इन टुकड़ों में से कुछ हैं - यह वही है जो व्यापार में विभाजित है।



DDD के दृष्टिकोण से, Subdomains को तीन प्रकारों में विभाजित किया गया है। और यहां मैं एक और बात कहना चाहता हूं: अक्सर किताबों और लेखों में सबडोमेन को केवल डोमेन में घटाया जाता है, लेकिन आमतौर पर इस मामले में जब इसे उपडोमेन प्रकार के साथ जोड़ा जाता है। यही है, जब वे "कोर डोमेन" कहते हैं, तो उनका मतलब कोर सबडोमेन है, कृपया इसमें भ्रमित न हों। इसने पहली बार में मेरे दिमाग को उड़ा दिया।

उप डोमेन को तीन प्रकारों में विभाजित किया जाता है।



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



दूसरा प्रकार सहायक उपडोमेन है। यह भी पैसा बनाने के लिए एक महत्वपूर्ण बात है, यह भी कुछ ऐसा है जिसके बिना यह असंभव है, लेकिन यह किसी तरह का पता नहीं है, एक वास्तविक प्रतिस्पर्धी लाभ है। यह वही है जो Core Subdomain सपोर्ट करता है। Domain-Driven Design लगाने के दृष्टिकोण से, इसका मतलब है कि सहायक उपडोमेन पर कम प्रयास खर्च किया जाता है, सभी मुख्य बलों को Core पर फेंक दिया जाता है।

उसी DotNext के लिए एक उदाहरण विपणन है। यह विपणन के बिना असंभव है, अन्यथा कोई भी सम्मेलन के बारे में नहीं जानता होगा, लेकिन सामग्री के बिना विपणन की आवश्यकता नहीं है।



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

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



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



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



एक क्लासिक उदाहरण: सबडोमेन के रूप में बहीखाता पद्धति, कैसे प्रक्रिया को मैप किया जाता है, स्वचालित है, उदाहरण के लिए, 1 सी बहीखाता पद्धति, एल्बा या "मेरा व्यवसाय" - किसी न किसी उत्पाद द्वारा स्वचालित है। यह लेखांकन का बाध्य संदर्भ है, जिसमें इसकी सर्वव्यापी भाषा है, इसकी अपनी शब्दावली है। यही उनके बीच का अंतर है



यदि हम DotNext पर लौटते हैं, तो, जैसा कि मैंने कहा, टिकट टाइमपैड के लिए मैप किए गए हैं, और जो सामग्री हमारे कोर सबडोमेन है उसे एक कस्टम एप्लिकेशन पर मैप किया जाता है जिसे हम सामग्री प्रबंधन के लिए विकसित कर रहे हैं।

बद्ध संदर्भ आकार

एक पल है जो कई सवाल उठाता है। बंधे हुए संदर्भ के लिए सही आकार कैसे चुनें? पुस्तकों में, कोई भी ऐसी परिभाषा पा सकता है: "बद्ध संदर्भ बिल्कुल ऐसा होना चाहिए कि सर्वव्यापी भाषा पूर्ण, सुसंगत, असंदिग्ध, असंदिग्ध, सुसंगत हो।" शांत परिभाषा, एक प्रसिद्ध मजाक से एक गणितज्ञ की शैली में: बहुत सटीक, लेकिन बेकार।

आइए चर्चा करें कि हम सभी को एक समान कैसे समझते हैं: क्या यह एक समाधान, या परियोजना, या नाम स्थान होना चाहिए - कौन सा पैमाने बंधे हुए संदर्भ से जुड़ा होना चाहिए?



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

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

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

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

लेकिन यह सब नहीं है। आपको एक बार फिर याद दिला दूं कि Domain-Driven Design बहुत है: भाषा के बारे में, लोगों के बारे में। और आप लोगों को अनदेखा नहीं कर सकते हैं और इस मामले में केवल तकनीकी मापदंड कर सकते हैं। इसलिए, मैंने यह लिखा है: एक संदर्भ एक्स-मैन के बराबर है । मुझे लगता था कि x 10 के बारे में है, लेकिन हमने इगोर लाबुटिन ( twitter.com/ilabutin ) के साथ थोड़ी बात की और सवाल खुला।

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

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

वास्तुकला और निर्भरता प्रबंधन

Domain-Driven Design के दृष्टिकोण से, यह वास्तव में कोई फर्क नहीं पड़ता कि आप किस आर्किटेक्चर को चुनते हैं। Domain-Driven Design इसके बारे में नहीं है; Domain-Driven Design भाषा और संचार के बारे में है।



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



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



चार-परत वास्तुकला मूल रूप से समान है, डोमेन परत अभी भी निर्भर करती है, और चूंकि यह निर्भर करता है, तीसरे पक्ष, अनावश्यक निर्भरताएं इसके लिए अपना रास्ता बनाएंगी।



और इस अर्थ में, वास्तुकला है जो इससे बचने की अनुमति देती है - यह प्याज-वास्तुकला ("प्याज") है। इसका अंतर यह है कि इसमें संकेंद्रित परतें होती हैं, निर्भरताएं बाहर से केंद्र तक जाती हैं। अर्थात्, बाहरी परत किसी भी आंतरिक पर निर्भर कर सकती है, आंतरिक परत बाहरी लोगों पर निर्भर नहीं कर सकती है।

सबसे बाहरी परत एक वैश्विक अर्थों में उपयोगकर्ता इंटरफ़ेस है (अर्थात, यह आवश्यक रूप से एक मानव यूआई नहीं है, यह REST API या कुछ भी हो सकता है)। और बुनियादी ढांचा, जो सामान्य तौर पर भी I / O जैसा दिखता है, वही डेटाबेस है, वास्तव में, एक डेटा लेयर। ये सभी चीजें बाहरी परत में हैं। यही है, जिसके कारण एप्लिकेशन किसी तरह कुछ डेटा, कमांड, और इसी तरह प्राप्त करता है, इसे बाहर निकाल दिया जाता है, और डोमेन परत को इन चीजों पर निर्भरता से छुटकारा मिलता है।

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

केंद्र में डोमेन परत है। जैसा कि हम देखते हैं, वह अब किसी भी चीज पर निर्भर नहीं करता है, वह अपने आप में एक चीज बन जाता है। और यही कारण है कि डोमेन परत को अक्सर "कोर" कहा जाता है, क्योंकि यह कोर है, जो कि केंद्र में है, जो कि तीसरे पक्ष की चीजों पर निर्भर नहीं करता है।



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

सामरिक पैटर्न के बारे में थोड़ा सा: अलग इंटरफ़ेस

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

आइए अपने माइक्रोसेवा के कोड पर वापस जाएं और देखें कि रिपॉजिटरी के साथ क्या हुआ।



डोमेन परत में IOrdersRepository.cs रिपॉजिटरी इंटरफ़ेस और इसके कार्यान्वयन, OrdersRepository.cs थे।

 using System.Linq; namespace DotNext.Sales.Core { public interface IOrdersRepository { Order GetOrder(long id); void SaveOrder(Order order); IQueryable<Order> GetOrders(); #region V2 int GetLast3YearsCompletedOrdersCountFor(long customerId); #endregion } } 

यहां हमने पिछले तीन वर्षों के लिए आदेश प्राप्त करने के लिए एक निश्चित विधि जोड़ दी है GetLast3YearsCompletedOrdersCountFor।

और उन्होंने इसे किसी भी रूप में लागू किया (इस मामले में, इकाई ढांचे के माध्यम से, लेकिन यह कुछ भी हो सकता है):

  public int GetLast3YearsCompletedOrdersCountFor(long customerId) { var threeYearsAgo = DateTime.UtcNow.AddYears(-3); return _dbContext.Orders .Count(o => o.CustomerId == customerId && o.State == OrderState.Completed && o.OrderDate >= threeYearsAgo); } 

देखिए क्या समस्या है। रिपॉजिटरी डोमेन लेयर में समाप्त हो गई, डोमेन लेयर में इसका कार्यान्वयन, लेकिन DateTime.UtcNow.AddYears (-3) के साथ शुरू होने वाला कोड, स्वाभाविक रूप से डोमेन लेयर से संबंधित नहीं है, और यह एक व्यावसायिक तर्क नहीं है। हां, LINQ इसे कम या ज्यादा मानवीय बनाता है, लेकिन अगर, उदाहरण के लिए, यहाँ SQL क्वेरीज़ थीं, तो सब कुछ पूरी तरह से दुखी होगा।

सेपरेटेड इंटरफेस पैटर्न का अर्थ यह है कि डोमेन लॉजिक में हम जिस सर्विस इंटरफेस का उपयोग करते हैं, वह डोमेन लेयर में घोषित किया जाता है। हम रिपॉजिटरी और इसी तरह की सेवाओं के बारे में बात कर रहे हैं जिसमें इन सेवाओं के कार्यान्वयन का विवरण व्यावसायिक तर्क नहीं है। व्यावसायिक तर्क इन सेवाओं के अस्तित्व का तथ्य है और डोमेन परत में उनके कॉलिंग और उपयोग का तथ्य है। इसलिए, रिपॉजिटरी इंटरफ़ेस डोमेन परत में रहता है, और कार्यान्वयन बुनियादी ढांचे की परत पर चलता है।

मैंने एक और विकल्प तैयार किया। कोर असेंबली में रिपॉजिटरी इंटरफ़ेस रहता है, लेकिन कार्यान्वयन Infrastructure.EF पर चलता है।



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

एक बार फिर भाषा के बारे में

चलो फिर से बात करते हैं, और फिर से, और फिर से भाषा के बारे में।

बहुत शुरुआत में, हमने डोमेन मॉडल "स्पीकर - टॉक - इवेंट" बनाया। मुझे लगता है कि किसी ने कोई विशेष सवाल नहीं उठाया है।

और यहाँ परिदृश्य है जिसके आधार पर हमने यह डोमेन मॉडल बनाया था:



देखें, स्क्रिप्ट रूसी में है, और डोमेन मॉडल अंग्रेजी में है।

गैर-अंग्रेजी बोलने वाले डेवलपर्स के लिए, यह कुछ ऐसा है जिसे आपको लगातार साथ रहना होगा।



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

, , , . , .

1, . , — , , .



1. PascalCase , , , , , , , - - .

, - ?



, use case, , . , . C#, , , . , , , .

, , Domain-Driven Design. , , , , C# . .

, - Continuous Integration. , , , - - . , - , , . , 95% , , Continuous Integration, , TeamCity . .

, . . , 1-, , . «» , . , , .



, Domain-Driven Design.

— , . Domain-Driven Design — , . — , , ubiquitous language. , , . , , , .

. , . - , , , , , , , , , , — . .

. . . . , , . DSL-. .NET-, - , , , , . , .

, - . , , ubiquitous language -. .

• marshinov . , DDD: , « DDD, CQRS Event Sourcing » . , , .
• , AutoMapper MediatR. , Domain-Driven Design, .
• «F# for fun and profit» , , F# Domain-Driven Design. , , , .
• , , .

, , GitHub .

DotNext:
, « , ». DotNext ( 15-16 ) . , 1 , .