Stored procedures बनाम विज़ुअल वर्कफ़्लो: लॉजिक कहाँ रहना चाहिए

इस निर्णय का असल मतलब क्या है

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

तो stored procedures बनाम visual workflows की बहस असल में इस बारे में है कि इन नियमों को कहाँ रखा जाए ताकि वे बदलने में आसान, टूटने में कठिन, और उन लोगों के लिए स्पष्ट रहें जो प्रक्रिया के मालिक हैं।

अधिकांश टीमों के पास लॉजिक के तीन संभावित “घर” होते हैं:

• डेटाबेस में (stored procedures, triggers, constraints): नियम डेटा के पास चलते हैं। यह तेज़ और सुसंगत हो सकता है, लेकिन गैर-DB विशेषज्ञों के लिए बदलना कठिन हो सकता है।
• विज़ुअल वर्कफ़्लोज़ में (drag-and-drop process builders): नियम कदमों और निर्णयों के रूप में व्यक्त होते हैं। जैसे-जैसे प्रक्रिया बदलती है, इसे पढ़ना, समीक्षा करना और समायोजित करना अक्सर आसान होता है।
• कस्टम कोड में (services, apps, scripts): नियम किसी प्रोग्रामिंग भाषा में लिखे जाते हैं। यह अधिकतम लचीलापन देता है, लेकिन बदलावों के लिए आम तौर पर अधिक इंजीनियरिंग अनुशासन और टेस्टिंग चाहिए।

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

अधिकांश सिस्टम कई तरह के बिज़नेस लॉजिक रखते हैं। सामान्य उदाहरणों में validation (required fields, allowed ranges), approvals, pricing और discounts, notifications, और access rules शामिल हैं।

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

मानदंड: आप किस चीज़ के लिए अनुकूलित कर रहे हैं

यह वास्तव में स्वाद का सवाल नहीं है। यह इस बारे में है कि आप किसको सुरक्षित रखना चाहते हैं: डेटा, सिस्टम बदलने वाले लोग, और परिवर्तन की गति।

वे परिणाम जो सबसे ज़्यादा मायने रखते हैं

अपने प्रोजेक्ट के लिए शीर्ष परिणामों का नाम दें। अधिकांश टीमें इनमें से किसी मिश्रण का संतुलन कर रही होती हैं:

• सहीपन (Correctness): नियम हर बार एक ही तरीके से चलना चाहिए, यहाँ तक कि लोड के दौरान भी।
• साफ़गोई (Clarity): कोई नया व्यक्ति बिना अनुमान लगाए समझ सके कि क्या होता है।
• गति (Speed): जब ज़रूरी हो तो लॉजिक तेजी से और डेटा के पास चलना चाहिए।
• ऑडिटेबिलिटी (Auditability): आपको साबित करना चाहिए कि किसने क्या बदला और कब चलाया गया।
• बदलाव की दर (Change rate): आपको उम्मीद है कि requirements हफ्ते दर हफ्ते बदलेंगी, सालाना नहीं।

आप दुर्लभ ही सभी पाँच को अधिकतम करते हैं। लॉजिक को डेटाबेस के नज़दीक धकेलने से correctness और speed सुधर सकती है, लेकिन यह उन लोगों के लिए clarity घटा सकता है जो SQL में नहीं रहते।

कौन लॉजिक बदलगा (और कितनी बार)

ईमानदार रहें कि दिन-प्रतिदिन कौन बदलाव संभालेगा। एक नियम जिसे ops को हर हफ्ते tweak करना है उसे stored procedure deploy करने के लिए DBA की ज़रूरत नहीं होनी चाहिए। वहीं, जो नियम पैसे को प्रभावित करता है उसे बिना समीक्षा के एडिट नहीं किया जाना चाहिए।

बदलाव घर्षण के संदर्भ में सोचें। यदि requirements अक्सर बदलती हैं, तो आप ऐसी जगह चाहते हैं जहाँ अपडेट सुरक्षित, दिखाई देने योग्य और तेजी से शिप किए जा सकें। विज़ुअल वर्कफ़्लो टूल (उदाहरण के लिए, AppMaster’s Business Process Editor) तब अच्छा काम कर सकते हैं जब बिज़नेस मालिक और इंजीनियरों को बिना लो-लेवल कोड संपादित किए लॉजिक पर सहयोग करना हो। अगर बदलाव दुर्लभ हों और नियम महत्वपूर्ण हो, तो उच्च घर्षण स्वीकार्य हो सकता है।

मालिकाना का प्रेशर-परीक्षण करने का एक तेज़ तरीका:

• रात के 2 बजे अगर यह टूटे तो किसे कॉल किया जाएगा?
• किसी नियम को पैच करने की कितनी तेज़ ज़रूरत है?
• क्या बदलावों को approvals या कागज़ी ट्रेल की ज़रूरत है?
• क्या कई ऐप्स एक ही नियम पर निर्भर करेंगे?
• क्या लॉजिक ज्यादातर डेटा shaping है, या बिज़नेस निर्णय?

शुरुआत में सीमाओं पर विचार करें। कुछ उद्योग सख्त access control, separation of duties, या विस्तृत logs की मांग करते हैं। साथ ही डेटा एक्सेस सीमाएँ विचार में रखें: अगर केवल कुछ सेवाओं को ही कुछ फ़ील्ड्स दिखनी चाहिए, तो यह प्रभावित करता है कि लॉजिक सुरक्षित रूप से कहाँ चल सकती है।

कब लॉजिक stored procedures में होता है

Stored procedures डेटाबेस के अंदर चलने वाले लॉजिक के हिस्से होते हैं। PostgreSQL में वे SQL (और कभी-कभी PL/pgSQL जैसी DB भाषा) में लिखे जाते हैं। आपकी ऐप के पंक्तियाँ खींचने, लूप चलाने और बदलाव वापस पुश करने की बजाय डेटाबेस वही काम वहीं करता है जहाँ डेटा रहता है।

एक अच्छा नियम सरल है: जब मुख्य काम डेटा की रक्षा और bulk डेटा वर्क है, तब लॉजिक डेटाबेस में रखें, न कि लोगों या सिस्टमों का समन्वय करने के लिए।

जहाँ stored procedures चमकते हैं

Stored procedures उन नियमों के लिए बहुत उपयुक्त हैं जो हमेशा सच्चे होने चाहिए, चाहे कोई भी ऐप या इंटीग्रेशन डेटाबेस को छुए। सोचें उन गार्डरेल्स की जो खराब डेटा को रोकते हैं।

वे set-based updates में भी बेहतर होते हैं, जहाँ एक स्टेटमेंट हजारों पंक्तियों को सुरक्षित और तेज़ी से अपडेट कर सकता है। सरल गणनाएँ जो केवल डेटा के बारे में हैं, जैसे totals की गणना या फिक्स्ड discount फॉर्मूला लागू करना, यहाँ रह सकती हैं जब इससे round trips घटती हैं और परिणाम सुसंगत रहते हैं।

उदाहरण: जब एक ऑर्डर को paid चिह्नित किया जाता है, एक procedure order status atomically अपडेट कर सकता है, inventory घटा सकता है, और एक audit row लिख सकता है। अगर कोई भी स्टेप फेल होता है, तो पूरा परिवर्तन rollback हो जाता है।

जब stored procedures जोखिमपूर्ण हो जाते हैं

Stored procedures को टेस्ट और version करना application कोड की तुलना में कठिन हो सकता है, खासकर अगर आपकी टीम डेटाबेस परिवर्तनों को असली रिलीज की तरह नहीं मानती। लॉजिक ऐप से “छुपा” भी हो सकता है, जिससे coupling बाद में सामने आता है।

डिबगिंग भी मुश्किल हो सकती है। त्रुटियाँ डेटाबेस संदेशों के रूप में सामने आ सकती हैं जिनमें उपयोगकर्ता ने क्या किया इसकी कम संदर्भ जानकारी होती है। नए साथियों को समझने में कठिनाई हो सकती है क्योंकि नियम ऐप और डेटाबेस के बीच विभक्त हैं, और डेटाबेस लॉजिक ऑनबोर्डिंग के दौरान आसानी से छूट सकता है।

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

कब लॉजिक विज़ुअल वर्कफ़्लो में फिट बैठता है

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

जब आप साझा समझ के बारे में परवाह करते हैं तब वे चमकते हैं। अगर product, ops, support, और engineering सभी को यह सहमति चाहिए कि एक प्रक्रिया कैसे काम करती है, तो विज़ुअल वर्कफ़्लो नियमों को दिखाई देने लायक बनाता है। वह दृश्यता अक्सर फ़र्क बनाती है कि “सिस्टम टूट गया है” और “प्रक्रिया पिछले हफ्ते बदली थी” के बीच।

विज़ुअल वर्कफ़्लोज़ approvals और reviews, routing, notifications और reminders, timed steps (2 दिन प्रतीक्षा, फिर escalate), और integrations (Stripe को कॉल करना, संदेश भेजना, CRM अपडेट करना) के लिए आम तौर पर उपयुक्त होते हैं।

उदाहरण: ग्राहक refund का अनुरोध करता है। वर्कफ़्लो order age चेक करता है, अगर यह threshold से ऊपर है तो manager को रूट करता है, approve होने पर finance को नोटिफ़ाई करता है, और ग्राहक को अपडेट भेजता है। हर चरण को साधारण भाषा में इंगित करना और चर्चा करना आसान होता है, जो stakeholders को साइन-ऑफ करने में मदद करता है और नए टीम सदस्यों को “क्यों” समझने में मदद करता है।

AppMaster जैसे टूल इस तरह के लॉजिक के लिए बनाए गए हैं: आप पथ, शर्तें और साइड-इफेक्ट्स (मैसेजेस, API कॉल, status बदलाव) देख सकते हैं बिना डेटाबेस स्क्रिप्ट से खोदने के।

वर्कफ़्लो को स्पैगेटी बनने से रोकने के लिए उन्हें छोटा और पठनीय रखें। हर वर्कफ़्लो को एक outcome दें, स्टेप और ब्रांच के लिए स्पष्ट नाम रखें, गहराई से nested निर्णय सीमित रखें, और यह लॉग करें कि महत्वपूर्ण चुनाव क्यों किए गए ताकि बाद में पूछा जा सके “यह क्यों हुआ?”।

जब कोई वर्कफ़्लो जटिल डेटा क्रंचिंग करने लगे या बहुत सी तालिकाओं को छूने लगे, तो यह आम तौर पर संकेत है कि लॉजिक का कुछ हिस्सा कहीं और ले जाना चाहिए। विज़ुअल वर्कफ़्लोज़ सबसे अच्छे कंडक्टर की तरह काम करते हैं, पूरे ऑर्केस्ट्रा नहीं।

कब कस्टम कोड सही उपकरण है

कस्टम कोड वह लॉजिक है जो आप सॉफ़्टवेयर के रूप में लिखते और बनाए रखते हैं: फ़ंक्शंस, सर्विसेज़, या छोटे लाइब्रेरी जो आपके ऐप का हिस्सा बनकर चलती हैं। यह सबसे लचीला विकल्प है, और इसलिए इसे जानबूझकर इस्तेमाल किया जाना चाहिए, डिफ़ॉल्ट रूप से नहीं।

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

कोड चुनने के मजबूत संकेत:

• समस्या algorithmic है (pricing rules, route planning, scoring, matching, fraud checks) और बहुत सारे edge cases हैं।
• आपको असामान्य integration चाहिए (एक पार्टनर API जिसमें अजीब auth, जटिल retries, सख्त idempotency नियम हों)।
• प्रदर्शन संवेदनशील है (उच्च-वॉल्यूम प्रोसेसिंग, भारी कंप्यूटेशन, सावधानीपूर्वक caching) और आपको कड़ा नियंत्रण चाहिए।
• आपको एक ही लॉजिक कई जगह शेयर करना है (web, mobile, batch jobs) बिना उसे कॉपी किए।
• आपको लॉजिक के चारों ओर मजबूत automated tests चाहिए क्योंकि गलतियाँ महंगी हैं।

कोड ownership को भी स्पष्ट करता है। एक टीम बदलाओं की समीक्षा की जिम्मेदारी ले सकती है, tests को पास रखने, और व्यवहार का दस्तावेज़ीकरण करने की। यह उस स्थिति से बेहतर है जहाँ “यह तीन वर्कफ़्लोज़ में रहता है और किसी को नहीं पता कौन सा पहले चलता है।”

उदाहरण: एक refund decision engine जो order history, fraud signals, shipping status, और time windows पर विचार करता है। आप approval steps को विज़ुअल वर्कफ़्लो में रख सकते हैं, लेकिन निर्णय अक्सर यूनिट टेस्ट्स और वर्शन कंट्रोल के साथ कोड के रूप में बेहतर रहता है।

कीमत वास्तविक है। कस्टम कोड को इंजीनियरिंग समय, समीक्षा, और ongoing रखरखाव चाहिए। बदलावों में आम तौर पर किसी वर्कफ़्लो की तुलना में लंबा समय लग सकता है, और आपको एक रिलीज़ प्रक्रिया चाहिए। AppMaster कुछ सामान्य हिस्सों को विज़ुअल लॉजिक और मॉड्यूल के साथ कवर करके कितनी कोड की आवश्यकता है उसे घटा सकता है, जबकि टीमों को सोर्स कोड एक्सपोर्ट करने और जहाँ ज़रूरत हो विस्तार करने देता है।

एक पुनरायोग्य चरण-दर-चरण फ्रेमवर्क

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

जब भी नया लॉजिक सामने आए, इस फ्रेमवर्क का उपयोग करें:

• नियम को एक वाक्य में लिखें, फिर लेबल लगायें। अगर यह वैध डेटा के बारे में है (constraints, uniqueness, totals जो मेल खाने चाहिए), तो यह एक डेटा नियम है। अगर यह कदमों और हैंडऑफ़्स के बारे में है (approvals, waits, notifications), तो यह एक प्रोसेस नियम है। अगर यह भारी गणित या जटिल रूपांतरण है, तो यह एक computation नियम है।
• पूछें कि कौन इसे एडिट करता है और कितनी बार। अगर गैर-तकनीकी लोगों को इसे साप्ताहिक रूप से बदलना है, तो इसे SQL या कोड रिलीज़ में दबोचना नहीं चाहिए। अगर यह दुर्लभ रूप से बदलता है और हर बार लागू होना चाहिए, तो डेटाबेस एक मजबूत उम्मीदवार है।
• फैल होने के प्रभाव और आवश्यक ऑडिट ट्रेल को जांचें। अगर गलती पैसे का नुकसान, अनुपालन मुद्दे, या मुश्किल-से-ठीक होने वाला डेटा पैदा कर सकती है, तो ऐसी जगह चुनें जहाँ स्पष्ट लॉगिंग और कड़ा नियंत्रण हो।
• स्थान चुनें और सीमा परिभाषित करें। इनपुट, आउटपुट, और त्रुटियों के बारे में स्पष्ट रहें। उदाहरण: “एक order_id दिए जाने पर, allowed_refund_amount लौटाएँ या एक स्पष्ट reason code।” यह बॉउंड्री लॉजिक को हर जगह फैलने से रोकती है।
• एक लेयर को पतला रखने का निर्णय लें। तय करें क्या अधिकांशतः “डंब” रखना चाहिए ताकि आप नियमों की नकल न करें। आम विकल्प हैं: डेटाबेस को पतला रखें (केवल डेटा इंटीग्रिटी), वर्कफ़्लोज़ को पतला रखें (केवल ऑर्केस्ट्रेशन), या कोड को पतला रखें (केवल glue)।

रूल ऑफ थम्ब: डेटा नियमों को डेटा के सबसे नज़दीक रखें, प्रोसेस नियमों को वर्कफ़्लो टूल में रखें, और computation नियमों को वहां रखें जहाँ उन्हें टेस्ट और वर्शन करना आसान हो।

यदि आप AppMaster जैसे प्लेटफ़ॉर्म का उपयोग कर रहे हैं, तो आप डेटाबेस को गार्डरेल्स (टेबल्स, रिश्ते, बेसिक constraints) की तरह मान सकते हैं और बिज़नेस प्रोसेस एडिटर में “कौन अगला क्या करेगा” वाले हिस्सों को रख सकते हैं, जबकि कस्टम कोड को उन मामूली मामलों के लिए रिज़र्व रखें जिनकी वाकई ज़रूरत है।

आम गलतियाँ जो गंदे सिस्टम बनाती हैं

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

डुप्लीकेशन क्लासिक समस्या है: वही नियम दो जगह मौजूद है, लेकिन समय के साथ वे अलग हो जाते हैं। उदाहरण: डेटाबेस refunds को $500 से ऊपर reject करता है जब तक approval record न हो, पर एक वर्कफ़्लो फिर भी उस अलग सीमा की जाँच करके भुगतान को भेज देता है। दोनों तब तक “काम” करते हैं जब तक पहला असली edge case नहीं आता, तब सपोर्ट के पास एक रहस्यमयी बग आता है।

छिपे हुए नियम अगले हैं। ट्रिगर्स, stored procedures, और डेटाबेस में किए गए त्वरित फिक्स वर्कफ़्लो या UI बना रहे लोगों के लिए अदृश्य हो सकते हैं। अगर नियम वर्कफ़्लो या API के पास दस्तावेज़ित नहीं है जिस पर यह निर्भर करता है, तो बदलाव अनुमान पर बन जाते हैं और टेस्टिंग trial-and-error बन जाती है।

ओवरस्टफ्ड वर्कफ़्लोज़ एक अलग तरह की गड़बड़ी बनाते हैं। कई ब्रांच वाले लंबी ड्रैग-एंड-ड्रॉप चेन एक नाज़ुक artifact बन जाती है जिसे कोई छूना नहीं चाहता। AppMaster जैसे टूल्स में ब्लॉक्स जोड़ना आसान है क्योंकि यह तेज़ होता है, पर आज की तेज़ी बाद में भ्रम में बदल सकती है अगर वर्कफ़्लो की कोई स्पष्ट सीमा न हो।

दो विपरीत “बहुत ज़्यादा” गलतियाँ दीर्घकालिक दर्द पैदा करती हैं:

• डेटाबेस में बहुत ज़्यादा: हर नीति परिवर्तन एक migration प्रोजेक्ट बन जाता है, और छोटे प्रोडक्ट ट्वीक डेटाबेस रिलीज़ पर इंतज़ार करते हैं।
• ऐप कोड में बहुत ज़्यादा: मूल डेटा नियम (required fields, allowed statuses, unique constraints) भूल जाते हैं, और खराब डेटा imports, admin tools, या भविष्य के integrations के माध्यम से सिस्टम में घुस जाता है।

एक सरल आदत अधिकांश समस्याओं को रोक देती है: प्रत्येक नियम को एक प्राथमिक घर में रखें, और लिख दें कि वह कहाँ रहता है और क्यों। अगर आप 10 सेकंड में जवाब नहीं दे सकते कि “यह कहाँ लागू होता है?”, तो आप पहले से ही गंदगी कर रहे हैं।

त्वरित जांच: 2 मिनट में फैसला करें

आप यह चुन रहे हैं कि कौन सा नियम सबसे आसान है सही, दिखाई देने लायक, और बदलने योग्य रखने के लिए।

एक प्रश्न से शुरू करें: क्या यह नियम डेटा सच्चाई के बारे में है, मतलब इसे कभी भी bypass नहीं किया जाना चाहिए? अगर हाँ, तो इसे डेटाबेस के नज़दीक रखें। अगर यह स्टेप्स, approvals, या notifications के बारे में है, तो इसे वर्कफ़्लो लेयर के पास रखें।

एक तेज़ चेकलिस्ट:

• क्या यह डेटा सच्चाई लागू कर रहा है (negative inventory रोकना, duplicate “active” रिकॉर्ड ब्लॉक करना)? डेटाबेस की ओर झुकें।
• क्या यह कई तालिकाओं को छूता है और set-based updates चाहिए (बहुत सारे rows एक साथ)? डेटाबेस की ओर झुकें।
• क्या इसे एक स्पष्ट, मानव-पठनीय ऑडिट ट्रेल चाहिए कि किसने कब क्या approve किया? वर्कफ़्लो की ओर झुकें।
• क्या गैर-इंजीनियरों को इसे साप्ताहिक या मासिक बदलने की ज़रूरत होगी? वर्कफ़्लो की ओर झुकें।
• क्या यह बाहरी सेवाओं को कॉल करता है (payments, messaging, AI)? एप्लिकेशन या वर्कफ़्लो की ओर झुकें, डेटाबेस नहीं।

अब विफलता के बारे में सोचें। एक नियम जो फेल कर सकता है उसे इस तरह फेल करना चाहिए कि इंसान उसे recover कर सके।

यदि आपको सुरक्षित retries और स्पष्ट error messages चाहिए, तो एक orchestration लेयर पसंद करें जहाँ आप state ट्रैक कर सकते हैं और exceptions step-by-step हैंडल कर सकते हैं। विज़ुअल वर्कफ़्लो टूल अक्सर यह आसान बनाते हैं क्योंकि प्रत्येक स्टेप स्पष्ट होता है और लॉग किया जा सकता है।

एक व्यावहारिक टाई-ब्रेकर:

• अगर सिस्टम को सही रहना चाहिए भले ही कोई नया ऐप बाद में लिखा जाए, तो इसे डेटाबेस में लागू करें।
• अगर प्रक्रिया ops टीमों द्वारा पढ़ी और समीक्षा की जानी चाहिए, तो इसे विज़ुअल वर्कफ़्लो में रखें।
• अगर इसमें जटिल integrations, भारी computation, या विशेष लाइब्रेरी शामिल हैं, तो कस्टम कोड का उपयोग करें।

उदाहरण: “Refund amount मूल भुगतान से अधिक नहीं हो सकता” यह correctness है, इसलिए इसे डेटा के पास लागू करें। “$500 से ऊपर के refunds को manager approval चाहिए और फिर Telegram संदेश भेजो” यह एक वर्कफ़्लो है। AppMaster में वह approval चैन Business Process Editor में स्वाभाविक रूप से फिट बैठता है, जबकि कड़े constraints डेटा मॉडल में रहते हैं।

उदाहरण परिदृश्य: approvals वाले refunds

एक सामान्य वास्तविक मामला एक ऐसा refund है जिसे एक निश्चित राशि से ऊपर manager approval चाहिए, साथ ही notifications और साफ़ ऑडिट ट्रेल भी चाहिए।

एक स्रोत-आफ-ट्रुथ पर शुरू करें: amounts और एक साफ़ status फ़ील्ड के साथ एक एकल Refund रिकॉर्ड (उदा.: requested, needs_approval, approved, rejected, processing, paid, failed)। सिस्टम का हर हिस्सा इन एक ही फ़ील्ड्स को पढ़े और लिखे, बजाय इसके कि अलग-अलग जगहों पर parallel states रखें।

डेटाबेस में क्या होना चाहिए

पैसे और डेटा consistency की रक्षा करने वाले नियमों को डेटा के सबसे नज़दीक रखें।

Constraints (और कभी-कभी एक stored procedure) का उपयोग यह सुनिश्चित करने के लिए करें कि आप captured payment amount से अधिक refund नहीं कर सकते, किसी ऑर्डर को जो पहले से पूरी तरह refund हो चुका है उसका refund नहीं कर सकते, उसी ऑर्डर के लिए दो active refund requests नहीं बना सकते, या refund approve होने के बाद महत्वपूर्ण राशियों को बदल नहीं सकते।

Atomic update भी यहाँ रखें: जब एक refund request बनती है, तो एक ही transaction में Refund row लिखें और Order totals अपडेट करें। अगर किसी भी write में विफलता हो, तो कुछ भी आंशिक रूप से अपडेट नहीं होना चाहिए।

विज़ुअल वर्कफ़्लो में क्या फिट बैठता है

Approval स्टेप्स प्रोसेस होते हैं, डेटा सुरक्षा नहीं। एक विज़ुअल वर्कफ़्लो request को सही manager तक रूट करने, निर्णय का इंतज़ार करने, status अपडेट करने, reminders भेजने, और requester को notify करने के लिए अच्छा घर है।

एक साधारण फ्लो हो सकता है: create request -> अगर राशि सीमा से ऊपर है तो status needs_approval सेट करें -> manager को notify करें -> अगर approve हो तो approved सेट करें -> requester को notify करें -> अगर 24 घंटे में कोई जवाब न मिले तो reminder भेजें।

AppMaster जैसे टूल में यह एक Business Process के रूप में साफ़ तौर पर मैप होता है जो status बदलावों पर प्रतिक्रिया करता है और ईमेल, SMS, या Telegram संदेश ट्रिगर करता है।

कस्टम कोड में क्या होना चाहिए

Payment providers के edge cases हमेशा नियमों या ड्रैग-एंड-ड्रॉप स्टेप्स में सही बैठते नहीं हैं। provider-specific लॉजिक कस्टम कोड में रखें, जैसे partial refunds with fees या multi-capture payments, webhook reconciliation (provider कहे “paid” पर आपकी ऐप कहे “processing”), और idempotency व retry handling जब provider timeout करे।

महत्वपूर्ण बात यह है कि कस्टम कोड अपने status स्वयं न बनाये। वह Refund रिकॉर्ड पढ़ता है, provider क्रिया करता है, फिर अगला status और confirmed amounts वापस लिखता है ताकि डेटाबेस वही लेजर बने जिस पर हर कोई भरोसा करे।

अगले कदम: निर्णय को टिकाऊ बनायें

एक अच्छा फ़ैसला तभी मददगार होता है जब वह छह महीने बाद भी सटीक रहे। लक्ष्य यह है कि “यह लॉजिक कहाँ रहता है?” का चुनाव आसान से देखा जा सके, आसानी से टेस्ट हो, और गलती से बाइपास करना कठिन हो।

एक सरल लॉजिक मैप बनायें: आपकी प्रमुख नियमों की एक छोटी सूची और आपने प्रत्येक के लिए चुना हुआ घर। इसे संक्षिप्त रखें और किसी भी नियम के बदलते ही अपडेट करें। नियम का नाम, जहाँ यह रहता है (database, workflow, custom code), क्यों (एक वाक्य), यह क्या पढ़ता/लिखता है, और कौन बदलाव को approve करता है, शामिल करें।

सीमाओं को गैर-वार्तालापीय (non-negotiable) के रूप में लिखें जो आपके सिस्टम की सुरक्षा करें जब लोग बाद में फीचर जोड़ें। एक उपयोगी प्रारूप है: “डेटाबेस X की गारंटी देता है” और “वर्कफ़्लो Y लागू करता है।” उदाहरण: डेटाबेस गारंटी देता है कि एक refund रिकॉर्ड बिना ऑर्डर के मौजूद नहीं हो सकता, जबकि वर्कफ़्लो यह लागू करता है कि $500 से ऊपर refunds को manager approval चाहिए।

बदलाव करने से पहले टेस्टिंग की योजना बनायें। बड़ी टेस्ट योजना की ज़रूरत नहीं है, बस कुछ केस जिन्हें आप हर बार नियम बदलने पर दोहराएँगे:

• हैप्पी पाथ (अपेक्षित इनपुट, अपेक्षित परिणाम)
• विफलता पाथ (मिसिंग डेटा, invalid status, duplicate request)
• concurrency (दो लोग एक ही कार्रवाई एक साथ ट्रिगर कर रहे हों)
• सुरक्षा (एक उपयोगकर्ता स्टेप्स स्किप करने की कोशिश कर रहा है या सीधे endpoint कॉल कर रहा है)

Ownership और review नियम भी निर्धारित करें। तय करें कौन stored procedures एडिट कर सकता है, कौन वर्कफ़्लोज़ एडिट कर सकता है, और क्या peer review चाहिए। यही जगहें हैं जहाँ कई सिस्टम या तो स्वस्थ रहते हैं या “किसी को नहीं पता यह क्यों काम करता” में पहुँच जाते हैं।

यदि आप drag-and-drop वर्कफ़्लोज़ बिना असली बैकएंड संरचना खोए चाहते हैं, तो AppMaster (appmaster.io) जैसा प्लेटफ़ॉर्म एक व्यावहारिक मध्य मार्ग हो सकता है: अपने डेटा को मॉडल करें, Business Process Editor में प्रक्रिया व्यक्त करें, और आवश्यकतानुसार regenerate और deploy करें।

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