Stored procedures vs visual workflows: logic কোথায় থাকা উচিত?

এই সিদ্ধান্তের বাস্তব অর্থ

ব্যবসায়িক লজিক হল সেই নিয়মগুলোর সমষ্টি যা সিদ্ধান্ত নেয় কী অনুমোদিত, পরবর্তী কী হবে, এবং বাস্তবে মানুষ যখন সিস্টেম ব্যবহার করে তখন সিস্টেমকে কী করতে হবে। এটা ডেটা নয়—এটা আচরণ: কে কী করতে পারবে, কোন শর্তে, এবং কোন পার্শ্বপ্রতিক্রিয়া ঘটবে।

সুতরাং stored procedures বনাম visual workflows কথোপকথনটা আসলে নিয়ে আসে যে এই নিয়মগুলো কোথায় থাকা উচিত যাতে সেগুলো পরিবর্তন করা সহজ থাকে, ভাঙা কঠিন হয়, এবং প্রসেসের মালিকদের জন্য পরিষ্কার থাকে।

অধিকাংশ টিমের কাছে লজিকের তিনটি সম্ভাব্য “বাড়ি” থাকে:

• ডেটাবেসে (stored procedures, triggers, constraints): নিয়মগুলো ডেটার কাছাকাছি চলে। এটা দ্রুত এবং কনসিস্টেন্ট হতে পারে, কিন্তু নন-ডেটাবেস বিশেষজ্ঞদের জন্য পরিবর্তন করা কঠিন হতে পারে।
• ভিজ্যুয়াল ওয়ার্কফ্লোতে (ড্র্যাগ-এন্ড-ড্রপ প্রসেস বিল্ডার): নিয়মগুলো ধাপ ও সিদ্ধান্ত হিসেবে প্রকাশ করা হয়। প্রক্রিয়া বদলালে পড়া, রিভিউ ও সমন্বয় করা সাধারণত সহজ হয়।
• কাস্টম কোডে (সার্ভিস, অ্যাপ, স্ক্রিপ্ট): নিয়মগুলো প্রোগ্রামিং ভাষায় লেখা হয়। সর্বোচ্চ নমনীয়তা দেয়, কিন্তু পরিবর্তনের জন্য সাধারণত বেশি ইঞ্জিনিয়ারিং শৃঙ্খলা ও টেস্টিং লাগে।

এই পছন্দটা দৈনন্দিন গতি এবং দীর্ঘমেয়াদী রক্ষণাবেক্ষণকে প্রভাবিত করে। ভুল জায়গায় লজিক রাখলে বিতরণ ধীর হয় (প্রতিটি পরিবর্তনের জন্য কেবল সেই এক ব্যক্তির দরকার যিনি ডেটাবেসটা জানেন), ত্রুটি বাড়ে (একাধিক জায়গায় নিয়ম নকল করা), এবং ডিবাগিং কষ্টকর হয় (কেউ জানে না কেন রেকর্ডটি বাতিল হলো)।

অধিকাংশ সিস্টেমে বিভিন্ন ধরনের বিজনেস লজিক থাকে—ভ্যালিডেশন (প্রয়োজনীয় ফিল্ড, অনুমোদিত রেঞ্জ), অ্যাপ্রুভাল, প্রাইসিং ও ডিসকাউন্ট, নোটিফিকেশন, এবং অ্যাক্সেস নিয়ম ইত্যাদি সাধারণ উদাহরণ।

প্রায়োগিকভাবে ভাবুন: ডেটাবেস ডেটা ইন্টিগ্রিটি রক্ষা করতে দারুণ, ভিজ্যুয়াল ওয়ার্কফ্লো ব্যবসায়িক প্রক্রিয়াগুলো প্রকাশ করতে দারুণ, এবং কাস্টম কোড সেই ক্ষেত্রে ভাল যখন রুলটি সঠিকভাবে মডেল করা কঠিন বা খুব জটিল। AppMaster-এর মত প্ল্যাটফর্ম মাঝে মধ্যেই দাঁড়ায়: আপনি ডেটা মডেল করতে পারেন, তারপর প্রক্রিয়াটি পড়তে সহজ ভিজ্যুয়াল লজিক হিসেবে বাস্তবায়ন করতে পারেন যাতে নিয়মগুলো বহু অ্যাপে ছড়িয়ে না পড়ে।

যে মানদণ্ডগুলো: আপনি কী অপ্টিমাইজ করছেন

এটি আসলে কোনও স্বাদগত প্রশ্ন নয়। এটি আপনি কী রক্ষা করতে চাইছেন—ডেটা, যারা সিস্টেম পরিবর্তন করে তারা, এবং পরিবর্তনের গতি—তার উপর নির্ভর করে।

যে আউটকামগুলো সবচেয়ে গুরুত্বপূর্ণ

প্রজেক্টের শীর্ষ লক্ষ্যগুলো নাম দিন। বেশিরভাগ টিম নিম্নলিখিতগুলোর মিশ্রণে ব্যালান্স করে:

• ক্ষমতা (Correctness): নিয়মগুলো প্রতিবার একইভাবে চলতে হবে, লোড থাকা সত্ত্বেও।
• স্বচ্ছতা (Clarity): একজন নতুন মানুষ অনুমান ছাড়াই কী হয় তা বুঝতে পারবে।
• গতি (Speed): যখন দরকার লজিক দ্রুত এবং ডেটার কাছে চালাতে হবে।
• অডিটযোগ্যতা (Auditability): কে কী বদলিয়েছে এবং কখন রান হয়েছে তা প্রমাণ করা লাগবে।
• পরিবর্তনের হার (Change rate): আপনি প্রত্যাশা করেন যে রিকোয়ারমেন্ট সপ্তাহিকভাবে বদলাবে, না কি বছরে।

আপনি বিরলভাবে এই পাঁচটার সবকটিই সর্বাধিক করুন। লজিককে বেশি ডেটাবেসের কাছে ঠেলে দিলে ক্ষমতা ও গতি বাড়তে পারে, কিন্তু SQL-এ না থাকা লোকেদের জন্য স্বচ্ছতা কমতে পারে।

কে লজিক পরিবর্তন করবে (কতটা ঘন)

দিন-প্রতি-দিন পরিবর্তনের মালিক কে হবে—এটি নিয়ে সৎ হন। যে রুল অপসকে প্রতি সপ্তাহে টুইক করতে হবে সেটি একটি DBA-কে stored procedure ডিপ্লয় করার উপর নির্ভর করা উচিত নয়। একই সময়ে, যে রুল টাকাকে প্রভাবিত করে তা যাচাই ছাড়া সম্পাদনীয় হওয়া উচিত নয়।

পরিবর্তন ঘর্ষণ (change friction) হিসাব করে ভাবুন। যদি রিকোয়ারমেন্ট ঘনভাবে বদলায়, আপনি এমন জায়গা চাচ্ছেন যেখানে আপডেটগুলো নিরাপদ, দৃশ্যমান, এবং দ্রুত শিপ করা যায়। ভিজ্যুয়াল ওয়ার্কফ্লো টুল (উদাহরণ: AppMaster’s Business Process Editor) তখন ভালো কাজ করে যখন বিজনেস মালিক ও ইঞ্জিনিয়াররা লজিক নিয়ে একসাথে কাজ করতে চান কোডের নিম্নস্তর এডিট না করেই। যদি পরিবর্তন বিরল হয় এবং রুলটি অত্যন্ত গুরুত্বপূর্ণ হয়, উচ্চ ঘর্ষণ গ্রহণযোগ্য হতে পারে।

দ্রুত মালিকানা টেস্ট করার উপায়:

• ভোর ২টায় ব্রেক হলে কারা পেজ হয়?\n- একটি রুল প্যाच করতে আপনাকে কত দ্রুত হতে হবে?\n- পরিবর্তনের অনুমোদন বা কাগজপত্রের ট্রেইল দরকার?\n- একাধিক অ্যাপ একই রুলের উপর নির্ভর করবে কি?\n- লজিকটি প্রধানত ডেটা গঠন করছে, না কি ব্যবসায়িক সিদ্ধান্ত নিচ্ছে?

প্রাথমিক সীমাবদ্ধতাগুলো জানুন। কিছু ইন্ডাস্ট্রি কড়া অ্যাক্সেস কন্ট্রোল, দায়িত্ব বিচ্ছিন্নতা, বা বিস্তারিত লগ চায়। ডেটা অ্যাক্সেস সীমাও বিবেচনা করুন: যদি কেবল নির্দিষ্ট সার্ভিসগুলোই নির্দিষ্ট ফিল্ড দেখতে পারবে, তাহলে সেটি লজিক কোথায় চালানো যায় তা প্রভাবিত করে।

কখন লজিক stored procedures-এ থাকা উচিত

Stored procedures হল ডেটাবেসের ভিতরে চলা লজিক। PostgreSQL-এ এগুলো SQL বা PL/pgSQL-এর মত ভাষায় লেখা হয়। আপনার অ্যাপ যদি সারি টেনে বের করে, লুপ করে, এবং আপডেট ফিরে পাঠায়—তার বদলে ডেটাবেস সেখানে কাজটি করে।

একটি সাধারণ রুল: যখন প্রধান কাজটা ডেটা রক্ষা করা এবং ব্যাচ ডেটা কাজ করা হয়, তখন ডেটাবেসেই লজিক রাখুন—মানুষ বা সিস্টেম সমন্বয় করার কাজ হলে নয়।

Stored procedures কোথায় উজ্জ্বল

Stored procedures এমন নিয়মের জন্য ভাল যেগুলো সবসময় সত্য থাকতে হবে, যেকোনো অ্যাপ বা ইন্টিগ্রেশন ডেটাবেস স্পর্শ করুক না কেন। খারাপ ডেটা ঢুকতে বাধা দেওয়ার জন্য গার্ডরেইল ভাবুন।

এগুলো সেট-ভিত্তিক আপডেটে অ্যাক্সেল করে, যেখানে একটাই স্টেটমেন্ট হাজার হাজার সারি নিরাপদে ও দ্রুত আপডেট করতে পারে। কেবল ডেটা সম্পর্কে সাধারণ গণনা, যেমন মোট নির্ণয় বা স্থির ডিসকাউন্ট ফর্মুলা প্রয়োগ করা—যদি এটি রাউন্ড ট্রিপ কমায় এবং ফল কনসিস্টেন্ট রাখে—তাহলেও ডেটাবেসেই থাকতে পারে।

উদাহরণ: যখন একটি অর্ডার paid হিসাবে চিহ্নিত হয়, একটি প্রোসিজার এটিকে অ্যাটোমিকভাবে আপডেট করে অর্ডার স্ট্যাটাস, ইনভেন্টরি কমায়, এবং একটি অডিট রো লেখে। কোনো ধাপ ব্যর্থ হলে পুরো পরিবর্তন রোলব্যাক হয়।

কখন stored procedures ঝুঁকিপূর্ণ হয়

Stored procedures টেস্ট ও ভার্সন করা অ্যাপ কোডের মতো সহজ নয়, বিশেষত যদি আপনার টিম ডেটাবেস পরিবর্তনগুলোকে প্রকৃত রিলিজের মতো বিবেচনা না করে। লজিক অ্যাপ থেকে “লুকানো” হয়ে যেতে পারে, ফলে পরে কাপলিং দেখা যায়।

ডিবাগিংও কঠিন। এররগুলো ডেটাবেস মেসেজ হিসেবে উঠে আসতে পারে যেখানে ব্যবহারকারী কী করেছিল তাতে কম প্রসঙ্গ থাকে। নতুন সহকর্মীরা সংগ্রাম করতে পারে কারণ নিয়মগুলো অ্যাপ এবং ডেটাবেসের মধ্যে ভাগ হয়ে আছে, এবং ডেটাবেস লজিক অনবোর্ডিংয়ের সময় সহজেই চোখে পড়ে না।

যদি আপনার বেশিরভাগ লজিক ভিজ্যুয়াল টুলে থাকে, stored procedures কে ছোট, স্থিতিশীল কোরের জন্য সংরক্ষণ করুন যা ডেটার কাছে চালাতে হবে। অন্য সবকিছু রাখুন সেখানে যেখানে পড়া, ট্রেস করা এবং পরিবর্তন করা সহজ।

কখন লজিক ভিজ্যুয়াল ওয়ার্কফ্লোতে মানায়

ভিজ্যুয়াল ওয়ার্কফ্লোগুলো ধাপে-ধাপে প্রক্রিয়া লজিক যা একটি চেকলিস্টের মতো পড়া যায়: যখন কিছু ঘটে, এই অ্যাকশনগুলো এই ক্রমে চালান, স্পষ্ট সিদ্ধান্ত পয়েন্টসহ। এগুলো ভারী গণনার চাইতে বেশি কাজ করে কিভাবে কাজ মানুষ, সিস্টেম ও সময়ের মধ্যে চলে সে সম্পর্কে।

যখন আপনার লক্ষ্য মিলিত বোধগম্যতা তখন এগুলো উজ্জ্বল হয়। যদি প্রোডাক্ট, অপস, সাপোর্ট এবং ইঞ্জিনিয়ারিং—সবাই মেনে নিতে চায় যে একটি প্রক্রিয়া কিভাবে কাজ করে—তাহলে ভিজ্যুয়াল ওয়ার্কফ্লো নিয়মগুলো দৃশ্যমান করে তোলে। এই দৃশ্যমানতাই প্রায়শই পার্থক্য তৈরি করে “সিস্টেম ভাঙেছে” এবং “এই প্রক্রিয়া গত সপ্তাহে বদলে গিয়েছিল”—এর মধ্যে।

ওয়ার্কফ্লো সাধারণত অ্যাপ্রুভাল ও রিভিউ, রাউটিং, নোটিফিকেশন ও রিমাইন্ডার, টাইমড স্টেপ (২ দিন অপেক্ষা করে তারপর এস্কেলেট), এবং ইন্টিগ্রেশন (Stripe কল করা, একটি মেসেজ পাঠানো, CRM আপডেট করা) এর জন্য ভাল।

উদাহরণ: একটি গ্রাহক রিফান্ড অনুরোধ করে। ওয়ার্কফ্লো অর্ডারের বয়স চেক করে, যদি থ্রেশহোল্ডের বেশি হয় তাহলে ম্যানেজারের কাছে রাউট করে, অনুমোদন হলে ফাইন্যান্সকে নোটিফাই করে, এবং গ্রাহককে আপডেট পাঠায়। প্রতিটি ধাপ সহজে নির্দেশযোগ্য এবং সাধারণ ভাষায় আলোচনার সুবিধা দেয়, যা স্টেকহোল্ডারদের সই করাতে সাহায্য করে এবং নতুন টিম মেম্বারকে “কেন” বোঝায়।

AppMaster-এর মত টুলগুলো এই ধরনের লজিকের জন্য নির্মিত: আপনি পথটি, শর্তগুলো, এবং পার্শ্বপ্রতিক্রিয়া (মেসেজ, API কল, স্ট্যাটাস পরিবর্তন) দেখতে পারেন, ডেটাবেস স্ক্রিপ্ট খুঁজে বের করার দায় ছাড়াই।

ওয়ার্কফ্লোকে স্প্যাগেটি বানিয়ে ফেলা থেকে রক্ষা করতে, সেগুলো ছোট ও পড়তে সহজ রাখুন। প্রতিটি ওয়ার্কফ্লোকে একটি আউটকাম দিন, ধাপ এবং শাখার জন্য পরিষ্কার নাম ব্যবহার করুন, গভীরভাবে নেস্টেড সিদ্ধান্ত সীমাবদ্ধ করুন, এবং কী সিদ্ধান্ত নেওয়া হয়েছে তা লগ করুন যাতে পরে আপনি জানতে পারেন “এটি কেন ঘটল?”

যখন কোন ওয়ার্কফ্লো জটিল ডেটা ক্রঞ্চিং করতে শুরু করে বা অনেক টেবিলে টাচ করে, তা সাধারণত ইঙ্গিত দেয় যে লজিকের একটি অংশ অন্য কোথাও সরিয়ে নেওয়া উচিত। ভিজ্যুয়াল ওয়ার্কফ্লো ভালো কাজ করে কন্ডাক্টরের মতো—পুরো অর্কেস্ট্রার নয়।

কখন কাস্টম কোড উপযুক্ত

কাস্টম কোড হল আপনি সফটওয়্যার হিসেবে লিখে ও রক্ষণাবেক্ষণ করেন: ফাংশন, সার্ভিস, বা ছোট লাইব্রেরি যা আপনার অ্যাপের অংশ হিসাবে চালায়। এটা সর্বোচ্চ নমনীয়তা দেয়, এবং এজন্যই এটি উদ্দেশ্যপ্রসূতভাবে ব্যবহার করা উচিত, ডিফল্ট হিসেবে নয়।

কোড তখনই যুক্তিযুক্ত যখন লজিকটি নিরাপদভাবে ডেটাবেস প্রোসিজারে বা ড্র্যাগ-এন্ড-ড্রপ ওয়ার্কফ্লোতে প্রকাশ করা কঠিন। যদি আপনি টুলগুলোকে সমস্যার সাথে খাপ খাইয়ে নিতে ঝুঁকছেন, কোড প্রায়ই পরিষ্কার এবং সঠিক রাখা সহজ করে।

কোডের জন্য শক্ত সংকেতগুলো:

• সমস্যা অ্যালগরিদমিক (প্রাইসিং রুল, রুট পরিকল্পনা, স্কোরিং, ম্যাচিং, ফ্রড চেক) এবং অনেক এজ-কেস আছে।
• আপনি একটি অস্বাভাবিক ইন্টিগ্রেশন চান (পার্টনার API যার অদ্ভুত অথ, জটিল রিট্রাই, কড়া আইডেম্পোটেন্সি নিয়ম)।
• পারফরম্যান্স সংবেদনশীল (উচ্চ-ভলিউম প্রোসেসিং, ভারী কম্পিউটেশন, যত্নশীল ক্যাশিং) এবং আপনাকে কড়া নিয়ন্ত্রণ দরকার।
• আপনাকে একই লজিক একাধিক জায়গায় শেয়ার করতে হবে (ওয়েব, মোবাইল, ব্যাচ জব) কপি না করে।
• ভুল হলে খরচ বেশি—সেজন্য লজিকের চারপাশে শক্ত অটোমেটেড টেস্ট দরকার।

কোড মালিকানা স্পষ্ট করে—একটি টিম রিভিউ, টেস্টিং, এবং ডকুমেন্টেশন বজায় রাখার দায় নিতে পারে। এটা ভালো যে “এটি তিনটি ওয়ার্কফ্লোতে রয়েছে এবং কেউ নিশ্চিত না কোনটি আগে চলে”—এর চেয়ে।

উদাহরণ: একটি রিফান্ড ডিসিশন ইঞ্জিন যা অর্ডার ইতিহাস, ফ্রড সিগন্যাল, শিপিং স্ট্যাটাস, ও টাইম উইন্ডো বিবেচনা করে। আপ্রুভাল ধাপগুলো ভিজ্যুয়াল ওয়ার্কফ্লোতেই রাখা যেতে পারে, কিন্তু সিদ্ধান্ত নিজেই কোডে থাকা প্রায়শই ভাল কারণ ইউনিট টেস্ট ও ভার্সনিং সহজ হয়।

দাম আছে: কাস্টম কোড ইঞ্জিনিয়ারিং সময়, রিভিউ, এবং চলমান রক্ষণাবেক্ষণ দাবি করে। পরিবর্তনগুলো ওয়ার্কফ্লো এডিট করার তুলনায় বেশি সময় নিতে পারে, এবং আপনাকে একটি রিলিজ প্রক্রিয়া রাখতে হবে। AppMaster কিছু সাধারণ অংশ ভিজ্যুয়াল লজিক ও মডিউলের মাধ্যমে কভার করে কত কোড দরকার কমিয়ে দিতে পারে, কিন্তু যখন সত্যি প্রয়োজন তখন টিমকে সোর্স কোড এক্সপোর্ট করে বাড়াতে দেয়।

পুনরায় ব্যবহার করার জন্য ধাপে-ধাপে ফ্রেমওয়ার্ক

টিমগুলো প্রায়শই সবচেয়ে কাজে লাগার অংশটি বাদ দিয়ে দেয়: নিয়মটি স্পষ্টভাবে লিখে রাখা, তারপর এমন একটি বাড়ি চয়ন করা যা সেই নিয়মের আচরণের সাথে মেলে।

নতুন লজিক এলেই এই ফ্রেমওয়ার্কটি ব্যবহার করুন:

• নিয়মটিকে এক বাক্যে লিখুন, তারপর এটিকে লেবেল করুন। এটা যদি বৈধ ডেটা সম্পর্কে হয় (constraints, uniqueness, totals মিলে যাওয়া), তাহলে এটি ডেটা রুল। এটি যদি ধাপ ও হ্যান্ডঅফ সম্পর্কে হয় (অ্যাপ্রুভাল, অপেক্ষা, নোটিফাই), তাহলে এটি একটি প্রক্রিয়া রুল। যদি এটি ভারী গাণিতিক বা জটিল ট্রান্সফরমেশন হয়, তাহলে এটি একটি কম্পিউটেশন রুল।
• প্রশ্ন করুন কে এটিকে এডিট করে এবং কত ঘন। যদি নন-টেকনিক্যাল লোকেরা এটিকে সাপ্তাহিকভাবে বদলাতে চায়, তাহলে SQL বা কোড রিলিজের ভেতরে না রাখুন। যদি এটি খুব কম বদলায় এবং প্রতিবার এনফোর্স করা জরুরি, ডেটাবেস শক্ত প্রার্থী।
• ফেইলিওর ইমপ্যাক্ট ও প্রয়োজনীয় অডিট ট্রেইল চেক করুন। যদি একটি ভুল টাকার ক্ষতি বা কমপ্লায়েন্সের সমস্যা তৈরি করতে পারে, তখন এমন জায়গা বেছে নিন যেখানে পরিষ্কার লগিং ও কড়া কন্ট্রোল আছে।
• লোকেশন বেছে নিন এবং সীমানা ডিফাইন করুন। ইনপুট, আউটপুট, এবং এররগুলো সম্পর্কে স্পষ্ট হোন। উদাহরণ: “Given an order_id, return allowed_refund_amount or a clear reason code.” এই সীমানা লজিককে চারিদিকে ছড়িয়ে পড়া থেকে রক্ষা করে।
• একটি লেয়ারকে পাতলা রাখুন। কোনটা মূলত “ডাম্ব” রাখা হবে সেটা ঠিক করুন যাতে আপনি নিয়ম নকল না করেন। সাধারণ পছন্দগুলো: ডেটাবেসকে পাতলা রাখা (শুধু ডেটা ইন্টিগ্রিটি), ওয়ার্্কফ্লোকে পাতলা রাখা (শুধু অর্কেস্ট্রেশন), বা কোডকে পাতলা রাখা (শুধু গ্লু)।

রুল অব থাম: ডেটা রুলগুলোকে ডেটার কাছাকাছি রাখুন, প্রক্রিয়ার রুলগুলোকে ওয়ার্কফ্লো টুলে রাখুন, এবং কম্পিউটেশন রুলগুলোকে সেখানে রাখুন যেখানে সেগুলো টেস্ট ও ভার্সন করা সহজ।

যদি আপনি AppMaster ব্যবহার করেন, আপনি ডেটাবেসকে গার্ডরেইল হিসেবে বিবেচনা করতে পারেন (টেবিল, রিলেশন, বেসিক কনস্ট্রেইন্ট), Business Process Editor-এ “কে কী করবে পরবর্তী” অংশ প্রকাশ করতে পারেন, এবং কেবল এমন কেসগুলোর জন্য কাস্টম কোড সংরক্ষণ করবেন যেগুলো באמת প্রয়োজন।

বিশৃঙ্খল সিস্টেম ঘটানোর সাধারণ ভুলগুলো

মেসি সিস্টেম সাধারণত একটি ভুল পছন্দের কারণে হয় না। এগুলো ঘটে যখন লজিক ছড়িয়ে পড়ে, লুকানো হয়, বা কপি করা হয় যতক্ষণ না কেউ নিশ্চিত নয় সিস্টেমটা আসলে কী করে।

ডুপ্লিকেশন ক্লাসিক সমস্যা: একই নিয়ম দুটি জায়গায় আছে, কিন্তু সময়ের সাথে সেগুলো পৃথক হয়ে যায়। উদাহরণ: ডেটাবেস ৪০০ টাকার বেশি রিফান্ড অ্যাপ্রুভ ছাড়া না করার নিয়ম রাখে, কিন্তু ওয়ার্কফ্লো এখনো পুরোনো সীমা চেক করে পেমেন্ট পাঠায়। উভয় জায়গাই “চলবে” যতক্ষণ না প্রথম আসল এজ-কেস আসে, তখন সাপোর্টের কাছে রহস্যময় বাগ আসে।

লুকানো নিয়ম পরের। ট্রিগার, stored procedures, এবং ডেটাবেসে তাড়াহুড়ো ফিক্সগুলো UI বা ওয়ার্কফ্লো নির্মাতাদের কাছে অদৃশ্য হতে পারে। নিয়ম যদি ওয়ার্কফ্লো বা API-এর কাছাকাছি ডকুমেন্টেড না থাকে, পরিবর্তন অনুধাবন ছাড়া হয়ে যায় এবং টেস্টিং ট্রায়াল ও এরর-ভিত্তিক হয়ে ওঠে।

ওভারস্টাফড ওয়ার্কফ্লো আলাদা ধরনের গন্ডগোল তৈরি করে। একটি দীর্ঘ ড্র্যাগ-এন্ড-ড্রপ চেইন যার ডজনখানিক শাখা আছে তা এমন একটি ভঙ্গুর বস্ত্তে পরিণত হয় যা কেউ স্পর্শ করতে চায় না। AppMaster-এর মত টুলে ব্লক যোগ করা সহজ—কিন্তু দ্রুততা আজকে বিভ্রান্তি হয়ে দাঁড়াতে পারে যদি ওয়ার্কফ্লোয়ের কোনো পরিষ্কার সীমানা না থাকে।

দুই বিপরীত “অতি বেশি” ভুল দীর্ঘ মেয়াদে কষ্ট দেয়:

• ডেটাবেসে খুব বেশি: প্রতিটি পলিসি পরিবর্তন মাইগ্রেশন প্রজেক্টে পরিণত হয়, এবং ছোট প্রোডাক্ট টুইকগুলো ডেটাবেস রিলিজের ওপর অপেক্ষা করে।
• অ্যাপ কোডে খুব বেশি: মৌলিক ডেটা রুল (প্রয়োজনীয় ফিল্ড, অনুমোদিত স্ট্যাটাস, ইউনিক কনস্ট্রেইন্ট) ভুলে যাওয়া হয়, এবং ইমপোর্ট বা অ্যাডমিন টুল বা ভবিষ্যৎ ইন্টিগ্রেশনে খারাপ ডেটা ঢুকে পড়ে।

একটি সহজ অভ্যাস অধিকাংশ রোধ করে: প্রতিটি নিয়মকে এক প্রধান বাড়িতে রাখুন, এবং লিখে রাখুন কোথায় আছে এবং কেন। যদি আপনি 10 সেকেন্ডে উত্তর দিতে না পারেন “এটি কোথায় এনফোর্স করা হয়?” তাহলে আপনি ইতিমধ্যেই বিশৃঙ্খলতা করের আওতায় পড়ছেন।

দ্রুত চেক: ২ মিনিটে সিদ্ধান্ত নিন

আপনি নির্বাচন করছেন যেখানে একটি রুল সবচেয়ে সহজে সঠিক, দৃশ্যমান, এবং পরিবর্তনযোগ্য থাকবে।

একটি প্রশ্ন দিয়ে শুরু করুন: এই রুল কি ডেটা সঠিকতার সম্পর্কে, অর্থাৎ এটা কখনো বাইপ করা যাবে না? যদি হ্যাঁ, তাহলে সেটি ডেটাবেসের কাছাকাছি ঠেলুন। যদি এটি ধাপ, অ্যাপ্রুভাল, বা নোটিফিকেশনের সম্পর্কে, তাহলে ওয়ার্কফ্লো লেয়ারের কাছে রাখুন।

দ্রুত চেকলিস্ট:

• এটা কি ডেটা সঠিকতা এনফোর্স করছে (নেগেটিভ ইনভেন্টরি প্রতিরোধ করা, ডুপ্লিকেট “active” রেকর্ড ব্লক করা)? ডেটাবেসের দিকে ঝুঁকুন।
• এটা কি অনেক টেবিল স্পর্শ করে এবং সেট-ভিত্তিক আপডেট প্রয়োজন (অনেক সারি একসঙ্গে)? ডেটাবেসের দিকে ঝুঁকুন।
• এটা কি কে কখন কী অ্যাপ্রুভ করেছে তার স্পষ্ট, মানব-পাঠযোগ্য অডিট ট্রেইল চায়? ওয়ার্কফ্লোয়ের দিকে ঝুঁকুন।
• কি নন-ইঞ্জিনিয়ার্সকে এটি সপ্তাহিক বা মাসিকভাবে বদলাতে হবে? ওয়ার্কফ্লোয়ের দিকে ঝুঁকুন।
• এটা কি বাহ্যিক সার্ভিসগুলো কল করে (পেমেন্ট, মেসেজিং, AI)? অ্যাপ্লিকেশন বা ওয়ার্কফ্লো; না ডেটাবেস।

এবার ব্যর্থতা নিয়ে ভাবুন। একটি রুল যা ব্যর্থ করতে পারে, তাকে এমনভাবে ব্যর্থ করা উচিত যে মানুষ পুনরুদ্ধার করতে পারে।

যদি আপনাকে নিরাপদ রিট্রাই এবং স্পষ্ট এরর মেসেজ দরকার হয়, একটি অর্কেস্ট্রেশন লেয়ার পছন্দ করুন যেখানে আপনি স্টেট ট্র্যাক ও এক্সসেপশন ধাপে ধাপে হ্যান্ডেল করতে পারেন। ভিজ্যুয়াল ওয়ার্কফ্লো টুলগুলো প্রায়ই এটা সহজ করে কারণ প্রতিটি ধাপ স্পষ্ট এবং লগ করা যায়।

একটি ব্যবহারিক টাই-ব্রেকার:

• কেউ পরে একটি নতুন অ্যাপ লিখলে সিস্টেমটি সঠিক থাকতে হবে—এবং আপনি নিশ্চিত করতে চান, তাহলে ডেটাবেসে এনফোর্স করুন।
• যদি প্রক্রিয়াটি অপস টিম পড়ে বুঝে রিভিউ করবে, তাহলে ভিজ্যুয়াল ওয়ার্কফ্লোতে রাখুন।
• জটিল ইন্টিগ্রেশন, ভারী গণনা, বা বিশেষ লাইব্রেরি লাগলে কাস্টম কোড ব্যবহার করুন।

উদাহরণ: “Refund amount cannot exceed original payment” এটি সঠিকতার নিয়ম, তাই ডেটার কাছে এনফোর্স করুন। “Refunds over 500 require manager approval and then send a Telegram message” এটি একটি ওয়ার্কফ্লো। AppMaster-এ ঐ অ্যাপ্রুভাল চেইন Business Process Editor-এ মানানসইভাবে থাকে, আর কঠোর কনস্ট্রেইন্টগুলো ডেটা মডেলে থাকে।

উদাহরণ দৃশ্য: অ্যাপ্রুভালসহ রিফান্ড

একটি সাধারণ বাস্তব-কেস হল এমন একটি রিফান্ড যা একটি নির্দিষ্ট পরিমাণের উপরে ম্যানেজার অ্যাপ্রুভাল, নোটিফিকেশন এবং পরিষ্কার অডিট ট্রেইল চায়।

শুরু করুন একটি একক সত্য উৎস (source of truth) সংজ্ঞায়িত করে: একটি একক Refund রেকর্ড যার পরিমাণ এবং একটি পরিষ্কার স্ট্যাটাস ফিল্ড (যেমন: requested, needs_approval, approved, rejected, processing, paid, failed)। সিস্টেমের প্রত্যেক অংশকে এই একই ফিল্ড পড়া ও লিখতে বলুন, পরিবর্তে আলাদা অঙ্গভঙ্গি স্টেটে রাখা থেকে।

ডেটাবেসে কী থাকা উচিত

টাকা ও ডেটা কনসিস্টেন্সি রক্ষার জন্য যে নিয়মগুলো নন-নেগোশিয়েবল—সেগুলো ডেটার সবচেয়ে কাছাকাছি রাখুন।

কনস্ট্রেইন্ট ব্যবহার করুন (এবং মাঝে মাঝে একটি stored procedure) নিশ্চিত করতে যে আপনি captured payment amount-এর বেশি রিফান্ড করতে পারবেন না, একটি অর্ডার যা সম্পূর্ণরূপে রিফান্ড হয়েছে তার পুনরায় রিফান্ড করা যাবে না, একই অর্ডারের জন্য দুটি active refund request তৈরি হবে না, বা রিফান্ড অনুমোদনের পরে প্রধান পরিমান পরিবর্তন করা যাবে না।

এছাড়াও এখানে অ্যাটোমিক আপডেট রাখুন: যখন একটি রিফান্ড অনুরোধ তৈরি হয়, তখন একটিমাত্র ট্রানজ্যাকশনে Refund রো লেখুন এবং Order totals আপডেট করুন। যদি কোনটা ব্যর্থ হয়, কিছুই আংশিকভাবে আপডেট হওয়া উচিত নয়।

ভিজ্যুয়াল ওয়ার্কফ্লোতে কী মানায়

অ্যাপ্রুভাল ধাপগুলো প্রক্রিয়া—ডেটা সুরক্ষার নয়। রাউটিং অনুরোধটি সঠিক ম্যানেজারের কাছে পাঠানো, সিদ্ধান্তের জন্য অপেক্ষা, স্ট্যাটাস আপডেট করা, রিমাইন্ডার পাঠানো, এবং অনুরোধকারীকে জানানো—এসবের জন্য ভিজ্যুয়াল ওয়ার্কফ্লো ভাল।

সরল ফ্লোটি হতে পারে: create request -> যদি amount limit ছাড়ায়, set status needs_approval -> ম্যানেজারকে নোটিফাই করুন -> অনুমোদিত হলে approved সেট করুন -> অনুরোধকারীকে জানান -> 24 ঘণ্টায় প্রতিউত্তর না হলে রিমাইন্ডার পাঠান।

AppMaster-এর মতো টুলে এটি Business Process হিসেবে স্পষ্টভাবে ম্যাপ হয়: স্ট্যাটাস পরিবর্তনে প্রতিক্রিয়া করে ইমেইল, SMS, বা Telegram মেসেজ ট্রিগার করে।

কাস্টম কোডে কী থাকা উচিত

পেমেন্ট প্রদানকারীদের এজ-কেসগুলো সবসময় রুল বা ড্র্যাগ-এন্ড-ড্রপ ধাপে ফিট হয় না। প্রোভাইডার-নির্দিষ্ট লজিক কাস্টম কোডে রাখুন, যেমন পার্শিয়াল রিফান্ডে ফি প্রয়োগ, মাল্টি-ক্যাপচার পেমেন্ট, ওয়েবহুক রিকনসিলিয়েশন (প্রোভাইডার বলে “paid” কিন্তু আপনার অ্যাপ বলছে “processing”), এবং প্রোভাইডারের টাইমআউটে আইডেম্পোটেন্সি ও রিট্রাই হ্যান্ডলিং।

মূল কথা: কাস্টম কোড নিজের স্ট্যাটাস উদ্ভাবন করুক না। এটি Refund রেকর্ড পড়বে, প্রোভাইডারে কাজ করবে, এবং পরবর্তী স্ট্যাটাস ও নিশ্চিত পরিমাণ লিখে দেবে যাতে ডেটাবেস সেই লেজার হিসাবে থাকে যাকে সবাই বিশ্বাস করে।

পরবর্তী ধাপ: সিদ্ধান্তটিকে টেকসই করুন

ভালো সিদ্ধান্ত তখনই উপকারে আসে যখন সেটি ছয় মাস পরও সত্য থাকে। লক্ষ্য হলো “এই লজিক কোথায় থাকে?” এই প্রশ্নের উত্তর সহজে দেখা যায়, সহজে টেস্ট করা যায়, এবং অনিচ্ছাকৃতভাবে বাইপাস করা কঠিন।

একটি সহজ লজিক মানচিত্র তৈরি করুন: আপনার মূল রুলগুলোর সংক্ষিপ্ত তালিকা এবং প্রতিটির জন্য আপনি কোন বাড়ি বেছে নিয়েছেন। এটি সংক্ষিপ্ত রাখুন এবং যখন কোনো রুল বদলে যায় তখন আপডেট করুন। রুলের নাম, কোথায় আছে (ডেটাবেস, ওয়ার্কফ্লো, কাস্টম কোড), কেন (এক বাক্যে), এটি কী পড়ে এবং কী লেখে, এবং পরিবর্তন অনুমোদন কে দেয়—এসব অন্তর্ভুক্ত করুন।

সীমানাগুলো লিখে রাখুন যা ভবিষ্যতে ফিচার যোগ করার সময় আপনার সিস্টেমকে রক্ষা করবে। একটি সহায়ক ফরম্যাট: “The database guarantees X” এবং “Workflows enforce Y.” উদাহরণ: ডেটাবেস গ্যারান্টি দেয় যে একটি refund record কোনো order ছাড়া থাকতে পারবে না, এবং ওয়ার্কফ্লো এনফোর্স করে যে 500 টাকার বেশি রিফান্ডে ম্যানেজার অ্যাপ্রুভাল লাগবে।

পরিবর্তন করার আগে টেস্টিং প্ল্যান করুন। বড় টেস্ট প্ল্যান দরকার নেই—কেবল কিছু কেস যা আপনি প্রতিবার রুল বদলালে পুনরায় চালাবেন:

• Happy path (প্রত্যাশিত ইনপুট, প্রত্যাশিত ফল)\n- Failure path (অনুপস্থিত ডেটা, অবৈধ স্ট্যাটাস, ডুপ্লিকেট অনুরোধ)\n- Concurrency (একসঙ্গে একই কাজ দুই জন চেষ্টা করলে কী ঘটে)\n- Security (একজন ব্যবহারকারী ধাপগুলো স্কিপ করে বা সরাসরি endpoint কল করে কি না)

মালিকানা ও রিভিউ নিয়মও ঠিক করুন। সিদ্ধান্ত নিন কে stored procedures এডিট করতে পারবে, কে ওয়ার্কফ্লো এডিট করতে পারবে, এবং কী peer review দরকার। অনেক সিস্টেম এখানেই সুস্থ থাকে বা “কেউ জানে না এটা কেন চলে” অবস্থা নিয়ে যায়।

যদি আপনি ড্র্যাগ-এন্ড-ড্রপ ওয়ার্কফ্লো চান কিন্তু বাস্তব ব্যাকএন্ড স্ট্রাকচার হারাতে চান না, AppMaster (appmaster.io) মত প্ল্যাটফর্ম ব্যবহার করে দেখতে পারেন: ডেটা মডেল করুন, Business Process Editor-এ প্রক্রিয়া প্রকাশ করুন, এবং চাহিদা বদলালে ফের জেনারেট ও ডেপ্লয় করুন।

একটি উচ্চ-প্রভাবশালী রুল বেছে নিন, এটিকে ম্যাপ করুন, সীমা যোগ করুন, এবং তিনটি টেস্ট কেস লিখুন। এই এক অভ্যাসই বেশিরভাগ লজিক ছড়িয়ে পড়া প্রতিরোধ করে।