एक साल पहले, मैक्सिम अर्शिनोव (मार्शिनोव) ने एक प्रस्तुति "इंस्टेंट डिज़ाइन" की। महान रिपोर्ट, करिश्माई वक्ता, अंत में उपयोगी सामग्री। इस रिपोर्ट ने मेरी समझ को बदल दिया कि मैं क्या कर रहा था - हममें से किसने पाइपलाइन वास्तुकला को सहज रूप से लागू करने की कोशिश नहीं की है? और फिर डीडीडी द्वारा कई गुना सुंदर समाधान हैं! इसने डोमेन-विशिष्ट डिज़ाइन में एक प्रचारक के रूप में मेरी यात्रा शुरू की।

डॉटनेक्स्ट 2019 मॉस्को जल्द ही आ रहा है। हमेशा की तरह, हम नई सुविधाओं, अनुभव के आदान-प्रदान, सर्वोत्तम प्रथाओं, वास्तु समाधानों की समीक्षा की प्रतीक्षा कर रहे हैं। रिपोर्ट की सूची में वोक शॉप "द शाइन एंड पॉवर्टी ऑफ द सब्जेक्ट मॉडल" है , जिसने मेरा ध्यान आकर्षित किया। पृष्ठ से उद्धरण:

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

उत्पादन खुद ही सोचता है कि डीडीडी आंदोलन के विकास में एक संकट पैदा हो गया है। उपयोग की शिथिलता और कट के तहत इस तरह की विकृतियों के कारणों का एक छोटा विश्लेषण।

विषय-उन्मुख डिजाइन के उपयोग की शिथिलता

वर्तमान स्थिति में कुछ ऐतिहासिक विकास है। आइए हम चरणों में विचार करें कि स्थिति कैसे विकसित हुई।

पदोन्नति

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

शिथिलता # 1: लाभप्रदता

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

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

डिसफंक्शन # 2: इंस्टेंट डिजाइन उर्फ ​​एनीमिक मॉडल उर्फ ​​सहमति

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

आप इवांस को काफी नहीं समझते हैं।

• क्लॉपस्टॉक की प्रशंसा कौन नहीं करता है? लेकिन क्या हर कोई इसे पढ़ेगा? नहीं। हम कम श्रद्धेय होना चाहते हैं, लेकिन अधिक परिश्रम से पढ़ें! (लेसिंग)।

मैं अब समझाता हूँ।

एनीमिक मॉडल एक एंटीपैटर्न है

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

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

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

लेकिन यह डीडीडी विचार के अंतःस्थावी अंत के साथ समाप्त नहीं हो सका।

व्यापार वस्तुओं के बाद दुविधा # 3 जीवन उपकरण की जटिलता उर्फ।

2019 के वसंत में, मैक्सिम और वागीब ने हमें बताया कि कैसे # में C # में F # के फीचर्स नहीं आए, कैसे F # में मॉडल को सही तरीके से बनाया जाए, इसके बारे में आसान है, कि कैसे फंक्शनलिज्म में OOP का उल्लंघन नहीं करना है। अब जनता यह मान सकती थी कि डीडीडी न केवल संगीत का आदेश देने के लिए सस्ती थी, बल्कि सभी मनुष्यों के लिए भी नहीं थी, लेकिन केवल वे जो कार्यात्मक प्रोग्रामिंग जानते थे।

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

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

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

यहां बिल्कुल घृणित है उपलब्धियों के लिए दृष्टिकोण का सरल मानव स्वभाव है - लोग स्वयं में ऐसी उपलब्धियों की सराहना करते हैं, उन्हें एक फॉर्म और लागू किए गए आवेदन के बिना। और यहां सूची लंबी हो सकती है। आइंस्टीन ने हमें एसटीओ, जीआर, एफई दिया, वह एक उत्कृष्ट वैज्ञानिक हैं, लेकिन औसत व्यक्ति से सापेक्षतावादी आंदोलन, समय के बारे में पूछते हैं - उसे आइंस्टीन की आवश्यकता नहीं है, लेकिन "स्मार्ट" वार्तालाप में कोई भी उल्लेख कर सकता है कि सब कुछ सापेक्ष है। फ्रायड के बारे में एक व्यक्ति से पूछें, एक महान मनोवैज्ञानिक, जिसने विज्ञान में गंभीर प्रगति की है, यदि यह व्यक्ति मनोविज्ञान का उपयोग करता है, उदाहरण के लिए, कल की दुःस्वप्न की व्याख्या करने के लिए - वह नहीं जीता, लेकिन वह किसी दिन कामुकता और जनता के मनोविज्ञान का उल्लेख करेगा। मार्क्स वह है जिसने समाजशास्त्र और इतिहास से विज्ञान को बनाया है, लेकिन किसी को वैज्ञानिक समाजवाद की आवश्यकता नहीं है, लेकिन हर कोई प्रगतिशील कर और ईमानदार लोकतंत्र के बारे में बात कर सकता है। समस्या उन्मुख डिजाइन का भी कोई रूप नहीं है - एरिक इवांस ने हमारे लिए नई ऊंचाइयां खोली हैं, सॉफ्टवेयर जटिलता को कम करने के लिए एक उत्कृष्ट उपकरण प्रदान करते हैं, लेकिन ओडीएसडी का उपयोग कैसे करें और क्या करना है यह स्पष्ट नहीं है, और आम तौर पर यह बिल्कुल भी काम नहीं करता है।

मुझे नहीं पता कि बाकी के बारे में कैसे, लेकिन विषय-उन्मुख डिजाइन के साथ आप गलतफहमी के कारणों को समझ सकते हैं।

उपयोग के संकट के कारण

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

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

परिणाम

अगर आप वास्तविक दुनिया की वस्तुओं का वर्णन कर रहे हैं तो DDD को हमेशा आजमाया जा सकता है। यह दृष्टिकोण पीएचपी में और वीबीए में लागू किया जा सकता है, और 1 सी (और डेवलपर्स लागू होते हैं)। दृष्टिकोण को लागू करने की समस्या लोगों के बीच संचार के विमान में अधिक होने की संभावना है, और प्रौद्योगिकी की मदद करने की अधिक संभावना है। संवाद करें, कोशिश करें, दूसरों को सिखाएं! सोफास्किल्स, एकजुटता, उद्देश्य की एकता को बढ़ावा दें। डीडीडी सिर्फ एक टीमवर्क तकनीक है।

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

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

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