"व्यावसायिक तर्क" का वास्तव में क्या मतलब है यदि "सभी गैर-तृतीय पक्ष कोड" नहीं है?


25

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

  • "व्यावसायिक तर्क आपके कार्यक्रम का हिस्सा है जो वास्तविक व्यावसायिक नियमों को एन्कोड करता है।" मैंने जो भी परिभाषाएँ पढ़ी हैं उनमें से अधिकांश इस तरह से गोलाकार हैं।

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

  • "आपके डेटा एक्सेस लेयर के ऊपर और आपके GUI लेयर के नीचे एक बिजनेस लॉजिक लेयर होना चाहिए।" मेरे द्वारा लिखे गए कोड में, डेटाबेस एक्सेसर्स को यह जानना होता है कि वे किस डेटा को एक्सेस करने वाले हैं, और यूआई कोड को यह जानने के लिए बहुत कुछ जानना होगा कि इसे सही तरीके से प्रदर्शित करने के लिए क्या करना है, और वास्तव में इसके बीच में कुछ भी नहीं है। क्लाइंट और सर्वर के बीच डेटा के ब्लॉब्स को पार करने के अलावा वे दो स्थान हैं। तो क्या वास्तव में एक व्यापार तर्क परत में जाना चाहिए?

  • "व्यावसायिक तर्क प्रस्तुति तर्क से अलग होना चाहिए।" अधिकांश फ़ीचर अनुरोध हमें व्यावसायिक कारणों से प्रेजेंटेशन लॉजिक बदलने के लिए मिलते हैं। यदि व्यापार नियमों में से एक को डिफ़ॉल्ट रूप से 32 वें अंक में अमेरिकी सरकार के बॉन्ड की कीमतों को प्रदर्शित करना है (जबकि उपयोगकर्ता को कॉन्फ़िगर करने के लिए यूआई प्रदान करते हुए), तो प्रस्तुति लॉजिक को कम से कम इस नियम का पता होना चाहिए, यदि यह पूरी तरह से लागू नहीं होता है। इसके अलावा, ऐसा लगता है कि यूएक्स डिजाइन का एक प्रमुख हिस्सा उपयोगकर्ता को उन व्यापार नियमों को समझने में मदद कर रहा है जिन्हें हमारे सॉफ्टवेयर लागू करने की कोशिश कर रहे हैं।

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

उत्तरों को ठोस बनाने में मदद करने के लिए: पहले से ही आपको डोमिनोज़ पिज्जा ऐप को फिर से लागू करना होगा। व्यावसायिक तर्क क्या है, और उस एप्लिकेशन का गैर-व्यावसायिक तर्क क्या है? और उस पिज़्ज़ा-ऑर्डरिंग बिजनेस लॉजिक को कोड के अपने "लेयर" में कैसे डालना संभव होगा, बिना डेटा की जानकारी और प्रेजेंटेशन लेयर्स के अधिकांश पिज्जा की जानकारी ब्लीडिंग के बिना?

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

मैं user61852 के उत्तर को स्वीकार कर रहा हूं क्योंकि इसने मुझे "व्यापार तर्क" के बारे में और अधिक ठोस समझ दी और इसका उल्लेख नहीं किया।


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

हमारे लिए इन्फ्रास्ट्रक्चर, लाइब्रेरी कोड और मचान ज्यादातर अन्य टीमों या 3 पार्टियों (हालांकि बॉयलरप्ले समान रूप से हर जगह फैले हुए हैं) द्वारा बनाए रखा जाता है, इसलिए शायद यह उतना ही सरल है जितना मैं यूआई / बिजनेस लॉजिक करने वाली टीम पर।
Ixrec

8
यदि आप $ 50 से अधिक ऑर्डर करते हैं, तो आपको मुफ्त पनीर-इंसट्रक्टेड ब्रेडस्टिक्स मिलते हैं।
kdgregory

1
@ raptortech97 वह / वह कह रही है कि "यदि आप $ 50 से अधिक का ऑर्डर करते हैं तो आपको मुफ्त पनीर-इंसुलेटेड ब्रेडस्टिक्स मिलते हैं" व्यापार तर्क है।
user253751

"यदि व्यापार नियमों में से एक को डिफ़ॉल्ट रूप से 32 वें अंक में अमेरिकी सरकार के बॉन्ड की कीमतों को प्रदर्शित करना है (जबकि उपयोगकर्ता को कॉन्फ़िगर करने के लिए यूआई प्रदान करना है), तो प्रस्तुति तर्क को कम से कम इस नियम का पता होना चाहिए" नहीं, नहीं, यह नहीं है टी और कुछ कहना नहीं चाहिए। यूआई के पास केवल एक लेबल / टेक्स्टबॉक्स / विजेट हो सकता है जो कि व्यापार तर्क (या शायद मॉडल, लेकिन ...) को जो भी स्ट्रिंग करता है उसे प्रदर्शित करने के लिए।
जोशुआ ड्रेक

जवाबों:


27

मैं आपको CRUD अनुप्रयोगों के बारे में कुछ सुझाव दूंगा , क्योंकि मुझे खेल या ग्राफिक रूप से गहन ऐप में बहुत अनुभव नहीं है:

  • व्यापार तर्क में आमतौर पर नियम शामिल होते हैं, जो व्यवसाय के मालिक ने सीखा है या ऑपरेशन के वर्षों में निर्णय लिया है, उदाहरण के लिए: "किसी भी नए क्रेडिट को अस्वीकार करें यदि ग्राहक ने अभी तक अंतिम भुगतान नहीं किया है" , या "हम नाश्ता नहीं बेचते हैं" पिछले 11 बजे " , या " सोमवार और मंगलवार, ग्राहक एक की कीमत के लिए दो पिज्जा खरीद सकते हैं "
  • बेशक प्रेजेंटेशन लेयर में एक संदेश दिखाई देना चाहिए जो किसी डिस्काउंट की उपलब्धता या क्रेडिट रिजेक्ट होने का कारण बताता है, लेकिन इस तरह की लेयर उन चीजों को तय नहीं कर रही है, यह केवल उस उपयोगकर्ता को कुछ बता रही है जो हुड के नीचे हुआ था।
  • व्यावसायिक तर्क में आमतौर पर एक वर्कफ़्लो शामिल होता है , उदाहरण के लिए: "इस आइटम को कुछ प्रबंधक द्वारा 3 कार्य दिवसों के भीतर सुरक्षित किया जाना चाहिए या 'सूचना के लिए अनुरोध' चरण में रखा जाना चाहिए, यदि ग्राहक ने आवश्यक दस्तावेज जमा नहीं किए हैं, तो आइटम अस्वीकार कर दिया गया है"
  • प्रस्तुति परत आमतौर पर उस तरह के वर्कफ़्लो से नहीं निपटती है, यह केवल वर्कफ़्लो की स्थिति को दर्शाती है।
  • इसके अलावा, डेटा एक्सेस लेयर आमतौर पर सीधी होती है, क्योंकि निर्णय पहले से ही व्यापार तर्क द्वारा किए जा रहे हैं। उदाहरण के लिए, जब आप MS SQL Server से Oracle में अपने डेटा को स्थानांतरित करने का निर्णय लेते हैं तो यह परत प्रभावित होती है
  • यह सच है कि कभी-कभी GUI सर्वर पर कॉल से बचने के लिए कुछ सत्यापन करता है, लेकिन यह कुछ ऐसा है जिसे विवेकपूर्ण तरीके से किया जाना चाहिए या आपके पास उस परत में बहुत सारे व्यावसायिक तर्क हो सकते हैं।
  • आपका अधिकांश भ्रम इस तथ्य से उत्पन्न हो सकता है कि आपके आवेदन में चिंताओं का कोई अलगाव नहीं है और प्रभावी रूप से आपके पास प्रस्तुति परत में बहुत अधिक व्यावसायिक तर्क हैं। तथ्य यह है कि आप (गलत तरीके से) आपके आवेदन परत में व्यावसायिक तर्क है या डेटा एक्सेस परत इस तथ्य को नहीं बदलती है कि यह व्यावसायिक तर्क है।
  • मीलों / गज / पैरों के बजाय मीट्रिक प्रणाली में दूरियों को प्रदर्शित करने वाली चीजें प्रस्तुति तर्क नहीं है, यह व्यावसायिक तर्क है । व्यवसाय की परत को आवश्यक इकाइयों में डेटा वापस करना है और प्रस्तुति परत को बताना है कि एपट्रैप लेबल्स को दिखाने के लिए वह किन इकाइयों को संभाल रहा है, लेकिन यह निश्चित रूप से एक व्यावसायिक तर्क चिंता है।
  • व्यावसायिक तर्क इससे प्रभावित नहीं होना चाहिए इस तथ्य से कि आप पोस्टग्रेज के बजाय अब ओरेकल का उपयोग कर रहे हैं, या इस तथ्य से कि कंपनी ने इसे लोगो या स्टाइल शीट में बदल दिया है।
  • व्यावसायिक नियम मौजूद हैं कि आप इसे स्वचालित करते हैं या नहीं एक ऐप लिखकर कर सकते हैं। उन्हें तब भी लागू किया जा सकता है जब व्यवसाय पेन और पेपर जैसे कम तकनीकी समाधान का उपयोग करता है।
  • यदि आपके पास अपने डेस्कटॉप ऐप का एक मोबाइल संस्करण है, या एक वेब संस्करण है , तो उन सभी संस्करणों में एक अलग प्रस्तुति परत है , लेकिन (उम्मीद है) एक ही व्यावसायिक परत है।

5

ऐसा लगता है कि आपके अधिकांश कार्य UI परत में हो सकते हैं। व्यावसायिक कारणों के लिए प्रदर्शन प्रारूप बदलना, कोई व्यावसायिक तर्क नहीं देता है। परिवर्तन दृश्य तर्क का परिवर्तन है।

प्रारूप को बदलने में सक्षम होने का मतलब है कुछ व्यावसायिक तर्क जिसमें संभवतः वरीयता की दृढ़ता शामिल है।

कुकी के प्रारूप को जारी रखना, दृश्य परत में भी लागू किया जा सकता है।

हालाँकि, इसे MVC तरीके से लागू किया जा सकता है। (कुछ मॉडल वरीयताओं से निपटने में सक्षम अपने स्वयं के एमवीसी के रूप में दृश्य को लागू करते हैं।)

  • उपयोगकर्ता की प्राथमिकता मॉडल (डेटाबेस / कुकी) द्वारा संग्रहीत की जा सकती है।
  • नियंत्रक मॉडल में उपयोगकर्ता की प्राथमिकता को बदलकर प्रारूप अनुरोधों पर प्रतिक्रिया करेगा।
  • दृश्य उपयोगकर्ता की प्राथमिकता को समायोजित करेगा। वरीयता मॉडल से अनुरोध की जा सकती है, या नियंत्रक द्वारा प्रदान की जा सकती है।

अपने आवेदन के बारे में शिक्षित अनुमान लगाना।

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

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

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

यह टूटने वाली चिंताओं को अलग करने की अनुमति देता है।

  • मॉडल द्वारा प्रस्तुत डेटा परत अपेक्षाकृत स्थिर होती है।
  • व्यावसायिक परत वह जगह है जहां व्यावसायिक निर्णय लागू होते हैं: क्या अनुरोध पूरा हो सकता है? क्या सभी आवश्यक डेटा प्राप्त किए गए हैं? क्या उपयोगकर्ता अधिकृत है? क्या लेनदेन पर कोई लाल झंडे हैं?
  • दृश्य परत कम स्थिर होती है, और एक से अधिक हो सकती है। यह वह जगह है जहां आवेदन का रूप और अनुभव रहता है। अन्य परतों को बदलने के बिना, एक आवेदन को पूरी तरह से फिर से त्वचा करना संभव है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.