২৯ অক্টো, ২০২৫·8 মিনিট
ওয়েব, মোবাইল এবং API-এর জন্য একটি একক এআই-উৎপাদিত কোডবেস
একটি একক এআই-উৎপাদিত কোডবেস কীভাবে ওয়েব, মোবাইল এবং API চালাতে পারে—শেয়ার করা লজিক, সঙ্গত ডেটা মডেল, এবং নিরাপদ রিলিজ নিশ্চিত করে।
একটি একক এআই-উৎপাদিত কোডবেস কীভাবে ওয়েব, মোবাইল এবং API চালাতে পারে—শেয়ার করা লজিক, সঙ্গত ডেটা মডেল, এবং নিরাপদ রিলিজ নিশ্চিত করে।
“একটি কোডবেস” বলতে সাধারণত একই UI সবখানে চলে বোঝায় না। প্রকটভাবে, এর মানে প্রায়ই একটি রিপোজিটরি এবং এক সেট শেয়ার করা নিয়ম—যেখানে আলাদা ডেলিভারি সারফেস (ওয়েব অ্যাপ, মোবাইল অ্যাপ, API) একই ভিত্তির ব্যবসায়িক সিদ্ধান্তগুলোর ওপর নির্ভর করে।
একটি দরকারী মেন্টাল মডেল হল সেই অংশগুলো শেয়ার করা যেগুলো কখনোই ভিন্ন হওয়া উচিত নয়:
এদিকে, সাধারণত আপনি পুরো UI লেয়ার শেয়ার করবেন না। ওয়েব এবং মোবাইলের নেভিগেশন, অ্যাক্সেসিবিলিটি, পারফরম্যান্স ও প্ল্যাটফর্ম ক্ষমতা আলাদা। UI শেয়ার করা কিছু ক্ষেত্রে সুবিধাজনক হতে পারে, কিন্তু সেটাই “একটি কোডবেস” এর সংজ্ঞা নয়।
AI-উৎপাদিত কোড উল্লেখযোগ্যভাবে দ্রুততা আনতে পারে:
কিন্তু AI স্বয়ংক্রিয়ভাবে সুসংহত আর্কিটেকচার তৈরি করে না। স্পষ্ট বাউন্ডারি ছাড়া এটি প্রায়ই অ্যাপগুলোর মধ্যে লজিক নকল করে, কনসার্ন মিশায় (UI সরাসরি DB কল করে), এবং একাধিক জায়গায় “প্রায় একই” ভ্যালিডেশন তৈরি করে। প্রকৃত লিভারেজ আসে যখন আপনি প্রথমে স্ট্রাকচার নির্ধারণ করেন—তারপর AI-কে পুনরাবৃত্তিমূলক অংশগুলো পূরণ করতে দেন।
একক AI-সহায়তা যুক্ত কোডবেস সফল যখন তা দেয়:
একটি একক কোডবেস কাজ করে তখনই যখন আপনি পরিষ্কার হন কী অর্জন করতে হবে—এবং কী স্ট্যান্ডার্ডাইজ করা উচিত নয়। ওয়েব, মোবাইল, এবং API আলাদা শ্রোতা ও ব্যবহারের ধারা সার্ভ করে, এমনকি যখন তারা একই ব্যবসায়িক নিয়ম শেয়ার করে।
অধিকাংশ প্রোডাক্টের অন্তত তিনটি “ফ্রন্ট ডোর” থাকে:
লক্ষ্যটি হল আচরণে কনসিস্টেন্সি (নিয়ম, পারমিশন, হিসাব) — অভিজ্ঞতা একই হওয়া নয়।
একটি সাধারণ ব্যর্থতার পথ হল “একটি কোডবেস” কে “একই UI” হিসেবে দেখা। সাধারণত এটা ওয়েব-র মতো মোবাইল বা মোবাইল-র মতো ওয়েব তৈরি করে—উভয়ই হতাশাজনক।
পরিবর্তে লক্ষ্য রাখুন:
অফলাইন মোড: মোবাইল প্রায়শই নেটওয়ার্ক ছাড়াই রিড এক্সেস (এবং কখনো কখনো রাইট) দরকার করে। এর মানে লোকাল স্টোরেজ, সিঙ্ক কৌশল, কনফ্লিক্ট হ্যান্ডলিং, এবং স্পষ্ট “সোর্স অফ ট্রুথ” নিয়ম।
পারফরম্যান্স: ওয়েব বাণ্ডল সাইজ ও টাইম-টু-ইন্টারঅ্যাকটিভ নিয়ে চিন্তা করে; মোবাইল স্টার্টআপ টাইম ও নেটওয়ার্ক দক্ষতা নিয়ে; API ল্যাটেন্সি ও থ্রুপুট নিয়ে। কোড শেয়ার করার মানে প্রতিটি ক্লায়েন্টকে অপ্রয়োজনীয় মডিউল পাঠানো নয়।
সিকিউরিটি ও কমপ্লায়েন্স: অথেনটিকেশন, অথরাইজেশন, অডিট ট্রেইল, এনক্রিপশন, এবং ডেটা রিটেনশন সব সারফেসে নিরপেক্ষভাবে一致 থাকা উচিত। যদি আপনি নিয়ন্ত্রিত এলাকায় কাজ করেন, তাহলে লগিং, কনসেন্ট, এবং লিস্ট-প্রিভিলেজ অ্যাক্সেস শুরু থেকেই বিল্ট ইন করুন—প্যাচ হিসেবে নয়।
একটি একক কোডবেস তখনই ভাল কাজ করে যখন এটি পরিষ্কার লেয়ারগুলোতে সংগঠিত থাকে এবং প্রতিটি লেয়ারের দায়িত্ব কঠোরভাবে সংজ্ঞায়িত। এই স্ট্রাকচার AI-উৎপাদিত কোডকে রিভিউ, টেস্ট, এবং পরিবর্তন করা সহজ করে—অপ্রাসঙ্গিক অংশ ভাঙার ঝুঁকি ছাড়াই।
এখানে বেশিরভাগ টিম যে মৌলিক আকৃতিতে একমত হয় তা:
Clients (Web / Mobile / Partners)
↓
API Layer
↓
Domain Layer
↓
Data Sources (DB / Cache / External APIs)
মূল ধারণাটি: ইউজার ইন্টারফেস এবং ট্রান্সপোর্ট ডিটেইলগুলি প্রান্তে থাকে, যখন ব্যবসায়িক নিয়ম কেন্দ্রে থাকে।
“শেয়ারেবল কোর” হলো সেই সবকিছু যা প্রতিটি জায়গায় একইভাবে আচরণ করা উচিত:
যখন AI নতুন ফিচার জেনারেট করে, সেরা ফলাফল হল: এটি একবার ডোমেইন নিয়ম আপডেট করে, এবং প্রতিটি ক্লায়েন্ট স্বয়ংক্রিয়ভাবে লাভবান হয়।
কিছু কোড শক্তভাবে শেয়ার করা ঝুঁকিপূর্ণ বা ব্যয়বহুল:
প্রায়োগিক নিয়ম: যদি ব্যবহারকারী এটি দেখতে পারে বা OS এটি ভাঙতে পারে, তাহলে এটি অ্যাপ-নির্দিষ্ট রাখুন। যদি এটি ব্যবসায়িক সিদ্ধান্ত হয়, ডোমেইনে রাখুন।
শেয়ার্ড ডোমেইন লেয়ার হলো সেই অংশ যা “নির্বিকার” হওয়া উচিত: পূর্বানুমেয়, টেস্টযোগ্য, এবং প্রতিটি জায়গায় পুনব্যবহারযোগ্য। যদি AI আপনার সিস্টেম তৈরিতে সাহায্য করে, এই লেয়ারটাই প্রকল্পের অর্থকে ল্যাঞ্চ করে—তাই ওয়েব স্ক্রিন, মোবাইল ফ্লো, এবং API এন্ডপয়েন্ট সব একই নিয়ম প্রতিফলিত করে।
আপনার পণ্যের মূল ধারণাগুলো সংজ্ঞায়িত করুন এনটিটি (পরিচয়সম্পন্ন বস্তু: Account, Order, Subscription) এবং ভ্যালু অবজেক্ট (ভ্যালু দ্বারা সংজ্ঞায়িত: Money, EmailAddress, DateRange) হিসেবে। তারপর আচরণগুলো ক্যাপচার করুন ইউজ—কেস (অ্যাপ্লিকেশন সার্ভিস): “Create order”, “Cancel subscription”, “Change email” ইত্যাদি।
এই স্ট্রাকচার ডোমেইনটিকে নন-স্পেশালিস্টদের জন্যও বোধগম্য রাখে: নামপদগুলি কী আছে বলে, ক্রিয়াগুলো কী করে বলে।
ডোমেইন লজিকে জানা উচিত না এটি কোন ট্রিগার করেছে—বাটন ট্যাপ, ওয়েব ফর্ম সাবমিশন, না API অনুরোধ। বাস্তবে এর মানে:
যখন AI কোড জেনারেট করে, এই বিভাজন হারানো সহজ—মডিউলগুলো UI কনসার্ন দিয়ে ভর্তি হয়ে যেতে পারে। একে রিফ্যাক্টর করার নির্দেশনা হিসেবে নিন, পছন্দ হিসেবে নয়।
ভ্যালিডেশনেই প্রায়ই ড্রিফট দেখা যায়: ওয়েব কিছু দেয় যা API প্রত্যাখ্যান করে, বা মোবাইল আলাদা ভ্যালিডেশন করে। ভ্যালিডেশনকে ডোমেইন লেয়ার (বা একটি শেয়ার্ড ভ্যালিডেশন মডিউল)-এ রাখুন যাতে সব সারফেস একই নিয়ম প্রয়োগ করে।
উদাহরণ:
EmailAddress একবার ফরম্যাট যাচাই করে, ওয়েব/মোবাইল/API সবখানে reusedMoney নেগেটিভ টোটাল ঠেকায়, যেখান থেকেই মান এসেছে তা নির্বিশেষেএটি ভালভাবে করলে, API লেয়ার হয় একজন অনুবাদক, আর ওয়েব/মোবাইল হয় প্রেজেন্টার—ডোমেইন লেয়ারই একমাত্র সত্যের উৎস থাকে।
API লেয়ার আপনার সিস্টেমের “পাবলিক ফেস” এবং একক AI-উৎপাদিত কোডবেসে এটি সেই অংশ হওয়া উচিত যা বাকি সবকিছুকে অ্যাঙ্কর করে। যদি কনট্র্যাক্ট স্পষ্ট হয়, ওয়েব অ্যাপ, মোবাইল অ্যাপ, এবং এমনকি ইন্টারনাল সার্ভিসগুলোও একই উৎস থেকে জেনারেট ও ভ্যালিডেট করা যায়।
কনট্র্যাক্ট জেনারেট করার আগে সংজ্ঞায়িত করুন:
/users, /orders/{id}), পূর্বানুমেয় ফিল্টারিং ও সোর্টিং।/v1/... বা হেডার-ভিত্তিক) এবং ডিপ্রিকেশনের নিয়ম নথিভুক্ত করুন।OpenAPI (বা GraphQL SDL-এর মতো স্কিমা-ফার্স্ট টুল) কে ক্যাননিকাল আর্টিফ্যাক্ট হিসেবে ব্যবহার করুন। সেখান থেকে জেনারেট করুন:
এটি AI-উৎপাদিত কোডের জন্য জরুরি: মডেল দ্রুত কোড তৈরি করতে পারে, কিন্তু স্কিমাই এটাকে সঙ্গত রাখে।
কয়েকটি অমি-নেগোশিয়েবল নীতি নির্ধারণ করুন:
snake_case না হলে camelCase; উভয় নয়; JSON ও জেনারেটেড টাইপসের মধ্যে মিল রাখুন।Idempotency-Key প্রয়োজন করুন (পেমেন্ট, অর্ডার তৈরি) এবং রিট্রাই আচরণ সংজ্ঞায়িত করুন।API কনট্র্যাক্টকে পণ্যের মত আচরণ করুন। যখন এটি স্থিতিশীল, বাকি সবকিছু জেনারেট, টেস্ট, এবং শিপ করা সহজ হয়ে যায়।
ওয়েব অ্যাপ শেয়ার্ড ব্যবসায়িক লজিক থেকে অনেক সুবিধা পায়—এবং কষ্ট পায় যখন সেই লজিক UI কনসার্নের সাথে জড়িয়ে পড়ে। মূলনীতি হল শেয়ার্ড ডোমেইন লেয়ারকে “হেডলেস” ইঞ্জিন হিসেবে বিবেচনা করা: এটি নিয়ম, ভ্যালিডেশন, এবং ওয়ার্কফ্লো জানে, কিন্তু কম্পোনেন্ট, রুট, বা ব্রাউজার API সম্পর্কে কিছুই জানে না।
যদি আপনি SSR (server-side rendering) ব্যবহার করেন, শেয়ার্ড কোড সার্ভারে চলার জন্য সেফ হতে হবে: সরাসরি window, document, বা ব্রাউজার স্টোরেজ কল করা যাবে না। এটি একটি ভালো জোরালো পদ্ধতি: ব্রাউজার-নির্ভর আচরণকে একটি পাতলা ওয়েব অ্যাডাপ্টার লেয়ারে রাখুন।
CSR (client-side rendering)-এ আপনি বেশি স্বাধীনতা পাবেন, কিন্তু একই ডিসিপ্লিন এখনও কার্যকর। CSR-মাত্রা প্রকল্পগুলো প্রায়ই “অকস্মাৎ” UI কোডকে ডোমেইনে ইমপোর্ট করে কারণ সবকিছু ব্রাউজারে চলে—পরবর্তীতে SSR, edge rendering, বা Node-এ চলা টেস্ট যোগ করলে সমস্যা দেখা দেয়।
প্রায়োগিক নিয়ম: শেয়ার্ড মডিউলগুলো ডিটারমিনিস্টিক এবং পরিবেশ-অ্যাগনস্টিক হওয়া উচিত; কুকি, localStorage, বা URL-কে স্পর্শ করা কিছুই ওয়েব অ্যাপ লেয়ারে থাকুক।
শেয়ার্ড লজিক ডোমেইন স্টেট (উদাহরণ: অর্ডার টোটাল, যোগ্যতা, ডেরাইভড ফ্ল্যাগ) সাদামাটা অবজেক্ট এবং পিউর ফাংশনের মাধ্যমে এক্সপোজ করতে পারে। ওয়েব অ্যাপকে UI স্টেট-এর দায়িত্ব নিতে হবে: লোডিং স্পিনার, ফর্ম ফোকাস, অপটিমিস্টিক অ্যানিমেশন, মডাল ভিজিবিলিটি।
এটি React/Vue স্টেট ব্যবস্থাপনাকে নমনীয় রাখে: লাইব্রেরি বদলালে ব্যবসায়িক নিয়মগুলো পুনরায় লেখার দরকার পড়বে না।
ওয়েব লেয়ারটি নিম্নলিখিত হ্যান্ডেল করা উচিত:
localStorage, ক্যাশিং)ওয়েব অ্যাপটিকে একটি অ্যাডাপ্টার হিসেবে ভাবুন: এটি ইউজার ইন্টারঅ্যাকশনকে ডোমেইন কমান্ডে অনুবাদ করে—আর ডোমেইন আউটকামকে অ্যাক্সেসিবল স্ক্রিনে রূপান্তর করে।
মোবাইল অ্যাপ শেয়ার্ড ডোমেইন লেয়ার থেকে সবচেয়ে বেশি সুবিধা পায়: মূল্যনীতি, যোগ্যতা, ভ্যালিডেশন, এবং ওয়ার্কফ্লো ফিচারগুলো ওয়েব ও API-র মতোই আচরণ করা উচিত। মোবাইল UI তারপর সেই শেয়ার্ড লজিককে ঘিরে একটি “শেল” হয়ে ওঠে—টাচ-উপযোগী, অনিয়মিত কানেক্টিভিটির উপযোগী, এবং ডিভাইস ফিচারগুলো ব্যবহার করে অপ্টিমাইজ করা।
শেয়ার্ড ব্যবসায়িক লজিক থাকলেও মোবাইলের প্যাটার্নগুলো সচরাচর ওয়েবের সাথে 1:1 মিলবে না:
যদি বাস্তব মোবাইল ব্যবহার আশা করেন, অফলাইনকে অনুমান করুন:
একটি “একক কোডবেস” দ্রুত ভাঙে যখন ওয়েব, মোবাইল, এবং API প্রত্যেকে আলাদা ডেটা শেপ এবং সিকিউরিটি নিয়ম আবিষ্কার করে। সমাধান হল মডেল, অথ, এবং অথরাইজেশনকে একটি শেয়ার্ড প্রোডাক্ট সিদ্ধান্ত হিসেবে ধরুন, তারপর একবার কোড করে নিন।
একটি জায়গা বেছে নিন যেখানে মডেলগুলি থাকে, এবং বাকিরা সেখান থেকেই ডিফার করুন। প্রচলিত অপশনগুলো:
টুলটি কী নয়—সমঞ্জস্যতা গুরুত্বপূর্ণ। যদি “OrderStatus” এক ক্লায়েন্টে পাঁচ মান থাকে আর অন্যটিতে ছয়, AI-উৎপাদিত কোড সুশৃঙ্খল কম্পাইল হলেও বাগ নিয়ে যাবে।
অথেনটিকেশন ব্যবহারকারীর কাছে একই অনুভূতি দিতে পারে, কিন্তু প্রযুক্তিগত বাস্তবায়ন সারফেসভেদে আলাদা হয়:
একটি একক ফ্লো ডিজাইন করুন: লগইন → স্বল্প-জীবী অ্যাক্সেস → প্রয়োজন হলে রিফ্রেশ → সার্ভার-সাইড স্টেট অব্যাহত রেখে লগআউট। মোবাইল-এ সিকিউর স্টোরেজে (Keychain/Keystore) সিক্রেট রাখুন; ওয়েব-এ httpOnly কুকি ব্যবহার করুন যাতে টোকেন JS-এ প্রকাশ না পায়।
পারমিশন একবার সংজ্ঞায়িত করুন—সর্বোৎকৃষ্টভাবে ব্যবসায়িক নিয়মের কাছে—তারপর সব জায়গায় প্রয়োগ করুন:
canApproveInvoice(user, invoice))।এটি “মোবাইল কাজ করে কিন্তু ওয়েবে না” ড্রিফট প্রতিরোধ করে এবং AI কোড জেনারেশনকে কে পারবে কি তা টেস্টেবল কনট্র্যাক্ট দেয়।
একটি ইউনিফায়েড কোডবেস ইউনিফায়েড থাকার জন্য বিল্ড এবং রিলিজ প্রেডিক্টেবল হতে হবে। লক্ষ্য হলো টিমগুলোকে API, ওয়েব, এবং মোবাইল স্বাধীনভাবে শিপ করার সুবিধা দেয়া—তবুও লজিক ফর্ক না করে এবং পরিবেশভিত্তিক “স্পেশাল কেস” না তৈরী করে।
একটি মনোরেপো (একটি রিপো, একাধিক প্যাকেজ/অ্যাপ) সাধারণত একটি একক কোডবেসের জন্য ভাল কাজ করে কারণ শেয়ার্ড ডোমেইন লজিক, API কনট্র্যাক্ট, এবং UI ক্লায়েন্টগুলো একসঙ্গে উন্নত হয়। আপনি অ্যাটমিক চেঞ্জ পাবেন (একটি PR এ একটি কন্ট্র্যাক্ট ও সব কনসিউমার আপডেট) এবং সহজ রিফ্যাক্টর।
মাল্টি-রেপো এখনও কাজ করতে পারে, কিন্তু সমন্বয়ে খরচ পড়ে: শেয়ার্ড প্যাকেজের সংস্করণ, আর্টিফ্যাক্ট পাবলিশিং, এবং ব্রেকিং চেঞ্জের সমন্বয়। যদি সংগঠনিক সীমা, সিকিউরিটি রুল, বা স্কেল আপ-ফ্যাক্টর থাকে তবে মাল্টি-রেপো বিবেচনা করুন।
প্রতিটি সারফেসকে আলাদা বিল্ড টার্গেট হিসেবে বিবেচনা করুন যা শেয়ার্ড প্যাকেজগুলো খায়:
বিল্ড আউটপুট এক্সপ্লিসিট এবং রেপ্রোডিউসিবল রাখুন (লকফাইল, পিন্ড টুলচেইন, ডিটারমিনিস্টিক বিল্ড)।
একটি টিপিক্যাল পাইপলাইন: lint → typecheck → unit tests → contract tests → build → security scan → deploy।
কনফিগ কোড থেকে আলাদা রাখুন: এনভায়রনমেন্ট ভেরিয়েবল এবং সিক্রেটগুলো আপনার CI/CD এবং সিক্রেট ম্যানেজারে রাখুন, রিপোতে নয়। dev/stage/prod ওভারলে ব্যবহার করুন যাতে একই আর্টিফ্যাক্ট বাই-আরও পরিবেশে পুনঃপ্রচার করা যায়—বিশেষ করে API এবং ওয়েব রানটাইমের জন্য।
ওয়েব, মোবাইল, এবং API এক সাথে শিপ করলে টেস্টিং আর একটি ‘‘আরও একটি চেকবক্স’’ নয়—এটি সেই মেকানিজম যা ছোট পরিবর্তনকে তিনটি প্রোডাক্টকে ভাঙতে দেয় না। লক্ষ্যটি সহজ: সমস্যা সস্তায় খুঁজে বের করুন, এবং ঝুঁকিপূর্ণ পরিবর্তনগুলো ব্যবহারকারীর কাছে পৌঁছানোর আগে বাধা দিন।
শেয়ার্ড ডোমেইন (ব্যবসায়িক লজিক) দিয়ে শুরু করুন কারণ সেটি সবচেয়ে পুনর্ব্যবহৃত এবং ইনফ্রাসট্রাকচার ছাড়াই টেস্ট করত সহজ।
এই স্ট্রাকচারটি বেশিরভাগ কনফিডেন্স ডোমেইন লজিকে রাখে, আবার লেয়ার সংযোগস্থলে “ওয়্যারিং” সমস্যাগুলো ধরা পড়ে।
মনোরেপোতেও, API এমনভাবে পরিবর্তিত হতে পারে যে কম্পাইল হয় কিন্তু ইউজার অভিজ্ঞতা ভাঙে। কনট্র্যাক্ট টেস্টগুলি নীরব ড্রিফট প্রতিরোধ করে।
ভাল টেস্ট গুরুত্বপূর্ণ, কিন্তু তাদের চারপাশের নিয়মও তেমনই গুরুত্বপূর্ণ।
এই গেটগুলো থাকলে AI-সহায়ত পরিবর্তনগুলো ঘন হলেও ভঙ্গুর হয় না।
AI একটি একক কোডবেস দ্রুত করতে পারে, কিন্তু কেবল তখনই যদি এটিকে দ্রুত জুনিয়র ইঞ্জিনিয়ারের মতো বিবেচনা করা হয়: ড্রাফট তৈরি করতে উত্তম, মার্জ করার আগে রিভিউ অপরিহার্য। লক্ষ্য হলো গতি পেতে হলেও আর্কিটেকচার, কনট্র্যাক্ট, এবং দীর্ঘমেয়াদি সঙ্গতিত্বের দায় মানুষের কাছে রেখে দেওয়া।
AI ব্যবহার করুন সেই “ফার্স্ট ভার্সন” তৈরিতে যেগুলো আপনি মেকানিক্যালভাবে লিখতেন:
একটি ভাল নিয়ম: AI কোড এমনভাবে উৎপাদন করুক যে পড়া বা টেস্ট চালিয়ে যাচাই করা সহজ হয়—না এমন কোড যেটা চুপচাপ ব্যবসায়িক অর্থ বদলে দেয়।
AI আউটপুটকে স্পষ্ট নিয়ম দ্বারা সীমাবদ্ধ করুন, মুড দ্বারা নয়। এই নিয়মগুলো কোডেই রাখুন:
AI যদি এমন শর্টকাট প্রস্তাব করে যা বাউন্ডারি ভাঙে, উত্তর হবে “না”, এমনকি যদি তা কম্পাইল করে।
ঝুঁকি কেবল খারাপ কোড নয়—ট্র্যাক করা না হওয়া ডিসিশনও। একটি অডিট ট্রেইল রাখুন:
AI সবচেয়ে মূল্যবান হয় যখন এটি পুনরাবৃত্তিযোগ্য: টিম দেখতে পারে কেন কিছু জেনারেট হয়েছে, যাচাই করতে পারে, এবং যখন দরকার পুনরায় সুরক্ষিতভাবে জেনারেট করতে পারে।
যদি আপনি সিস্টেম-পর্যায়ে AI-সহায়তা গ্রহণ করেন (ওয়েব + API + মোবাইল), সবচেয়ে গুরুত্বপূর্ণ “ফিচার” কাঁচামাল জেনারেশনের গতি নয়—এটি আউটপুটগুলোকে আপনার কন্ট্র্যাক্ট ও লেয়ারিং-এর সাথে সামঞ্জস্য রাখার ক্ষমতা।
উদাহরণস্বরূপ, Koder.ai একটি ভিব-কোডিং প্ল্যাটফর্ম যা টিমগুলোকে চ্যাট ইন্টারফেসের মাধ্যমে ওয়েব, সার্ভার, এবং মোবাইল অ্যাপ তৈরি করতে সাহায্য করে—তারপরও বাস্তব, এক্সপোর্টযোগ্য সোর্স কোড উৎপাদন করে। ব্যবহারিকভাবে, এটি এই আর্টিকেলে বর্ণিত ওয়ার্কফ্লোরের জন্য উপযোগী: আপনি একটি API কন্ট্র্যাক্ট ও ডোমেইন নিয়ম সংজ্ঞায়িত করে দ্রুত React-ভিত্তিক ওয়েব সারফেস, Go + PostgreSQL ব্যাকএন্ড, এবং Flutter মোবাইল অ্যাপ ইটারেট করতে পারেন আর্কিটেকচার বাউন্ডারিগুলো হারানোর ঝুঁকি ছাড়াই। প্ল্যানিং মোড, স্ন্যাপশট, এবং রোলব্যাকের মতো ফিচারগুলোও “জেনারেট → যাচাই → প্রোমোট” রিলিজ ডিসিপ্লিনের সাথে ভালোভাবে মানানসই।
একক কোডবেস ডুপ্লিকেশন কমাতে পারে, কিন্তু এটি সর্বদা “সেরা” পছন্দ নয়। যেই মুহূর্তে শেয়ার করা কোড অদক্ষ UX চাপিয়ে দেয়, রিলিজ ধীর করে, বা প্ল্যাটফর্ম পার্থক্য লুকায়, তখন আপনি আর্কিটেকচার নিয়ে আলোচনায় বেশি সময় ব্যয় করবেন অভাবে ভ্যালু শিপ করার পরিবর্তে।
আলাদা কোডবেস (অন্তত আলাদা UI লেয়ার) প্রায়শই উপযুক্ত যখন:
একটি একক কোডবেস নিশ্চিত করার আগে জিজ্ঞাসা করুন:
যদি সতর্ক সংকেত দেখা দেয়, একটি ব্যবহারিক বিকল্প হলো শেয়ার্ড ডোমেইন + API কন্ট্র্যাক্ট, কিন্তু অলাদা ওয়েব ও মোবাইল অ্যাপ। শেয়ার্ড কোডকে ব্যবসায়িক নিয়ম ও ভ্যালিডেশনে সীমাবদ্ধ রাখুন, এবং প্রতিটি ক্লায়েন্টকে UX ও প্ল্যাটফর্ম ইন্টিগ্রেশনের মালিক রাখুন।
যদি আপনি পথ নির্বাচন করতে সহায়তা চান, /pricing দেখে বিকল্প তুলনা করুন অথবা সম্পর্কিত আর্কিটেকচার প্যাটার্নগুলো /blog-এ ব্রাউজ করুন।
এটি সাধারণত মানে হল একটি রিপোজিটরি এবং এক সেট শেয়ার করা নিয়ম, একই অ্যাপ নয়।
প্রায়োগিকভাবে, ওয়েব, মোবাইল, এবং API সাধারণত একটি ডোমেইন লেয়ার (ব্যবসায়িক নিয়ম, ভ্যালিডেশন, ইউজ—কেস) এবং প্রায়ই একটি একক API কন্ট্র্যাক্ট শেয়ার করে, যখন প্রতিটি প্ল্যাটফর্ম তাদের নিজস্ব UI এবং প্ল্যাটফর্ম ইন্টিগ্রেশন রাখে।
শেয়ার করুন সেই জিনিসগুলো যেগুলো কখনোই অসম্মতি দেখাবেনা:
UI কম্পোনেন্ট, নেভিগেশন, এবং ডিভাইস/ব্রাউজার ইন্টিগ্রেশন প্ল্যাটফর্ম-নির্দিষ্ট রাখা উচিত।
AI স্ক্যাফল্ডিং এবং পুনরাবৃত্ত কাজ (CRUD, ক্লায়েন্ট, টেস্ট) দ্রুত করে দিয়ে দেয়, কিন্তু এটি স্বয়ংক্রিয়ভাবে ভালো বাউন্ডারি তৈরি করে না。
অন্তর্ভুক্ত না করলে AI-উৎপাদিত কোড প্রায়ই:
AI-কে সংজ্ঞায়িত লেয়ারগুলো পূরণ করার জন্য ব্যবহার করুন, লেয়ার নিজে আবিষ্কার করার জন্য নয়।
সহজ, নির্ভরযোগ্য ফ্লো হলো:
এটি ব্যবসায়িক নিয়ম কেন্দ্রীভূত রাখে এবং টেস্টিং ও AI-উৎপাদিত সংযোজনগুলো রিভিউ করা সহজ করে।
ভ্যালিডেশন এক জায়গায় রাখুন (ডোমেইন বা একটি শেয়ার্ড ভ্যালিডেশন মডিউল), তারপর সবখানে তা পুনব্যবহার করুন।
প্র্যাকটিক্যাল প্যাটার্নগুলো:
EmailAddress, Money ইত্যাদি ভ্যালিডেট একবারএটি “ওয়েব গ্রহণ করে, API প্রত্যাখ্যান করে” ড্রিফট প্রতিরোধ করে।
একটি ক্যাননিকাল স্কিমা (উদাহরণ: OpenAPI) ব্যবহার করে সার্ভার স্টাব, ভ্যালিডেশন, এবং ক্লায়েন্ট টাইপ জেনারেট করুন:
তারপর কনট্র্যাক্ট টেস্ট যোগ করুন যেন স্কিমা-ব্রেকিং পরিবর্তনগুলি CI-তে মেইর্জ হওয়ার আগে ফেল করে।
অফলাইন আর্কাইভটি উদ্দেশ্যপ্রণোদিতভাবে ডিজাইন করুন, কেবল ক্যাশিংর ওপর ভরসা করবেন না:
অফলাইন স্টোরেজ এবং সিঙ্ক মোবাইল অ্যাপ লেয়ারে রাখুন; ব্যবসায়িক নিয়ম শেয়ার্ড ডোমেইন কোডে রাখুন।
একটি ধারণাগত ফ্লো ব্যবহার করুন, প্রতিটি সারফেস অনুসারে বাস্তবায়িত:
অনুমোদন নিয়ম কেন্দ্রিকভাবে সংজ্ঞায়িত করুন (উদাহরণ: canApproveInvoice) এবং API-তে বাধ্যতামূলক রূপে এনফোর্স করুন; UI শুধুমাত্র ক্রিয়াগুলো লুকাতে/নিষ্ক্রিয় করতে ব্যবহার করুক।
প্রত্যেক সারফেসকে আলাদা বিল্ড টার্গেট হিসেবে বিবেচনা করুন, শেয়ার্ড প্যাকেজগুলো ব্যবহার করে:
CI/CD-তে: lint → typecheck → unit tests → contract tests → build → security scan → deploy চালান, এবং সিক্রেট/কনফিগ কোডের বাইরে রাখুন।
AI-কে দ্রুত জুনিয়র ইঞ্জিনিয়ারের মতো ব্যবহার করুন: ড্রাফট তৈরিতে পারদর্শী, মিশ্রিত হলে রিভিউ প্রয়োজন।
ভালো গার্ডরেইলগুলো:
যদি AI আউটপুট আর্কিটেকচার নিয়ম ভাঙে, তবে কম্পাইল করলেও প্রত্যাখ্যান করুন।