प्रोग्रामिंग प्रतिमान। डेटा ड्रिवेन बनाम डोमेन ड्रिवेन

लीप और बाउंड्स द्वारा सूचना प्रौद्योगिकियां विकसित हो रही हैं, नए डिवाइस, प्लेटफॉर्म, ऑपरेटिंग सिस्टम दिखाई दे रहे हैं, और साथ ही, डेवलपर्स द्वारा हल किए जाने वाले कार्यों की श्रेणी बढ़ रही है। लेकिन, सब कुछ इतना बुरा नहीं है - नए विकास उपकरण, ideh'ski, नई प्रोग्रामिंग भाषाएं, कार्यप्रणाली, इत्यादि हैं, जो कि परीक्षकों की मदद करने के लिए दौड़ रहे हैं। अकेले प्रोग्रामिंग प्रतिमानों की सूची प्रभावशाली है, और आधुनिक बहु- प्रतिमान प्रोग्रामिंग भाषाओं (उदाहरण के लिए, C #) को देखते हुए, सवाल यह उठता है: “इस सब से कैसे निपटें? क्या चुनना है?

आइए इसे थोड़ा जानने की कोशिश करते हैं।

इतने सारे प्रतिमान कहाँ से आए?

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

क्या चुनना है?

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

प्रतिमानों को वर्गीकृत करने के लिए, मैं 4 आयामों का उपयोग करता हूं जो लगभग किसी भी कार्य में निहित हैं:

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

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

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

निम्नलिखित उदाहरणों पर विचार करें:

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

क्या अभ्यास में?

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

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

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

डोमेन संचालित, बदले में, बड़ी परियोजनाओं के लिए फायदेमंद है, और छोटे लोगों के लिए यह समाधान को जटिल बनाता है और अधिक विकास संसाधनों की आवश्यकता होती है, जो अक्सर व्यावसायिक आवश्यकताओं के दृष्टिकोण से महत्वपूर्ण होता है (एक छोटे बजट के लिए "asap" बाजार में एक परियोजना लाने के लिए)।

दृष्टिकोणों में अंतर को समझने के लिए, अधिक विशिष्ट उदाहरण पर विचार करें। मान लें कि हमें लेखांकन आदेशों के लिए एक प्रणाली विकसित करने की आवश्यकता है। हमारे पास ऐसी संस्थाएँ हैं:

• उत्पाद
• ग्राहक
• कोटा (ग्राहक को प्रस्ताव के रूप में भेजा गया)
• आदेश (आदेश)
• चालान (भुगतान)
• आपूर्तिकर्ता को आदेश दें
• बिल (वास्तव में, आपूर्तिकर्ता से भुगतान)

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

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

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

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

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

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

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

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

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

इसके अलावा, आप मॉडलिंग त्रुटियों से प्रतिरक्षा नहीं कर सकते हैं, जिससे जटिल रीफैक्टरिंग हो सकती है।

तो डेटा संचालित बनाम डोमेन संचालित को संक्षेप में प्रस्तुत करने के लिए:
डेटा संचालित :

• आकर्षण आते हैं
  
  • आपको किसी एप्लिकेशन या प्रोटोटाइप को तेज़ी से विकसित करने की अनुमति देता है
  • डिजाइन करने के लिए सुविधाजनक (योजना के अनुसार कोड पीढ़ी, आदि)
  • छोटे या मध्यम आकार की परियोजनाओं पर, यह काफी समाधान हो सकता है।
  
  
• विपक्ष
  
  • विरोधी पैटर्न के लिए नेतृत्व और OOP से बच सकते हैं
  • बड़ी परियोजनाओं पर, यह अराजकता, जटिल समर्थन, आदि की ओर जाता है।
  
  

डोमेन संचालित:

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

तो मुझे क्या चुनना चाहिए?

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