ওয়েব, মোবাইল এবং API-এর জন্য একটি একক এআই-উৎপাদিত কোডবেস

একক এআই-উৎপাদিত কোডবেস মানে কী

“একটি কোডবেস” বলতে সাধারণত একই UI সবখানে চলে বোঝায় না। প্রকটভাবে, এর মানে প্রায়ই একটি রিপোজিটরি এবং এক সেট শেয়ার করা নিয়ম—যেখানে আলাদা ডেলিভারি সারফেস (ওয়েব অ্যাপ, মোবাইল অ্যাপ, API) একই ভিত্তির ব্যবসায়িক সিদ্ধান্তগুলোর ওপর নির্ভর করে।

শেয়ার্ড লজিক বনাম শেয়ার্ড UI

একটি দরকারী মেন্টাল মডেল হল সেই অংশগুলো শেয়ার করা যেগুলো কখনোই ভিন্ন হওয়া উচিত নয়:

• ডোমেইন নিয়ম: হিসাব-কাঠামো, যোগ্যতা চেক, মূল্য নির্ধারণ, ওয়ার্কফ্লো, ইনভারিয়ান্ট।
• ইউজ—কেস: “অর্ডার তৈরি”, “সাবস্ক্রিপশন বাতিল”, “রিফান্ড ইস্যু” ইত্যাদি।
• ডাটা কনট্র্যাক্ট: রিকোয়েস্ট/রেসপন্স শেপ, ভ্যালিডেশন নিয়ম, এরর কোড।

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

AI কী বদলায় (আর কী বদলায় না)

AI-উৎপাদিত কোড উল্লেখযোগ্যভাবে দ্রুততা আনতে পারে:

• প্রকল্প স্ক্যাফোল্ডিং (ফোল্ডার, বিল্ড স্ক্রিপ্ট, মৌলিক কম্পোনেন্ট)
• CRUD এন্ডপয়েন্ট ও ক্লায়েন্ট জেনারেশন
• উদাহরণ থেকে টেস্ট ও ফিক্সচার তৈরি

কিন্তু AI স্বয়ংক্রিয়ভাবে সুসংহত আর্কিটেকচার তৈরি করে না। স্পষ্ট বাউন্ডারি ছাড়া এটি প্রায়ই অ্যাপগুলোর মধ্যে লজিক নকল করে, কনসার্ন মিশায় (UI সরাসরি DB কল করে), এবং একাধিক জায়গায় “প্রায় একই” ভ্যালিডেশন তৈরি করে। প্রকৃত লিভারেজ আসে যখন আপনি প্রথমে স্ট্রাকচার নির্ধারণ করেন—তারপর AI-কে পুনরাবৃত্তিমূলক অংশগুলো পূরণ করতে দেন।

লক্ষ্যগুলো যা অর্জন করতে চান

একক AI-সহায়তা যুক্ত কোডবেস সফল যখন তা দেয়:

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

ওয়েব, মোবাইল, এবং API ডেলিভারির জন্য লক্ষ্য ও সীমাবদ্ধতা

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

আপনি কার জন্য তৈরি করছেন (এবং কীভাবে)

অধিকাংশ প্রোডাক্টের অন্তত তিনটি “ফ্রন্ট ডোর” থাকে:

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

লক্ষ্যটি হল আচরণে কনসিস্টেন্সি (নিয়ম, পারমিশন, হিসাব) — অভিজ্ঞতা একই হওয়া নয়।

নন-গোল: অভিন্ন UX জোর না করা

একটি সাধারণ ব্যর্থতার পথ হল “একটি কোডবেস” কে “একই UI” হিসেবে দেখা। সাধারণত এটা ওয়েব-র মতো মোবাইল বা মোবাইল-র মতো ওয়েব তৈরি করে—উভয়ই হতাশাজনক।

পরিবর্তে লক্ষ্য রাখুন:

• শেয়ার করা ডোমেইন লজিক এবং ভ্যালিডেশন
• শেয়ার করা ডেটা মডেল এবং API কনট্র্যাক্ট
• প্ল্যাটফর্ম-নির্দিষ্ট প্রেজেন্টেশন ও ইন্টারঅ্যাকশন ডিজাইন

প্রাথমিকভাবে ডিজাইন করার জন্য গুরুত্বপূর্ণ সীমাবদ্ধতা

অফলাইন মোড: মোবাইল প্রায়শই নেটওয়ার্ক ছাড়াই রিড এক্সেস (এবং কখনো কখনো রাইট) দরকার করে। এর মানে লোকাল স্টোরেজ, সিঙ্ক কৌশল, কনফ্লিক্ট হ্যান্ডলিং, এবং স্পষ্ট “সোর্স অফ ট্রুথ” নিয়ম।

পারফরম্যান্স: ওয়েব বাণ্ডল সাইজ ও টাইম-টু-ইন্টারঅ্যাকটিভ নিয়ে চিন্তা করে; মোবাইল স্টার্টআপ টাইম ও নেটওয়ার্ক দক্ষতা নিয়ে; API ল্যাটেন্সি ও থ্রুপুট নিয়ে। কোড শেয়ার করার মানে প্রতিটি ক্লায়েন্টকে অপ্রয়োজনীয় মডিউল পাঠানো নয়।

সিকিউরিটি ও কমপ্লায়েন্স: অথেনটিকেশন, অথরাইজেশন, অডিট ট্রেইল, এনক্রিপশন, এবং ডেটা রিটেনশন সব সারফেসে নিরপেক্ষভাবে一致 থাকা উচিত। যদি আপনি নিয়ন্ত্রিত এলাকায় কাজ করেন, তাহলে লগিং, কনসেন্ট, এবং লিস্ট-প্রিভিলেজ অ্যাক্সেস শুরু থেকেই বিল্ট ইন করুন—প্যাচ হিসেবে নয়।

রেফারেন্স আর্কিটেকচার: লেয়ার ও দায়িত্ব

একটি একক কোডবেস তখনই ভাল কাজ করে যখন এটি পরিষ্কার লেয়ারগুলোতে সংগঠিত থাকে এবং প্রতিটি লেয়ারের দায়িত্ব কঠোরভাবে সংজ্ঞায়িত। এই স্ট্রাকচার AI-উৎপাদিত কোডকে রিভিউ, টেস্ট, এবং পরিবর্তন করা সহজ করে—অপ্রাসঙ্গিক অংশ ভাঙার ঝুঁকি ছাড়াই।

উচ্চ-স্তরের ফ্লো

এখানে বেশিরভাগ টিম যে মৌলিক আকৃতিতে একমত হয় তা:

Clients (Web / Mobile / Partners)
          ↓
     API Layer
          ↓
    Domain Layer
          ↓
 Data Sources (DB / Cache / External APIs)

মূল ধারণাটি: ইউজার ইন্টারফেস এবং ট্রান্সপোর্ট ডিটেইলগুলি প্রান্তে থাকে, যখন ব্যবসায়িক নিয়ম কেন্দ্রে থাকে।

কী শেয়ার করা হয়

“শেয়ারেবল কোর” হলো সেই সবকিছু যা প্রতিটি জায়গায় একইভাবে আচরণ করা উচিত:

• ডোমেইন (ব্যবসায়িক লজিক): মূল্যনীতি, যোগ্যতা চেক, অর্ডার স্টেট ট্রানজিশন ইত্যাদি।
• ভ্যালিডেশন: ইনপুট নিয়ম এবং এরর মেসেজগুলো নিখুঁত কোডে ম্যাপ করা।
• নেটওয়ার্কিং + স্কিমা: API রিকোয়েস্ট/রেসপন্স টাইপ, সিরিয়ালাইজেশন, এবং কন্ট্র্যাক্ট টেস্ট।

যখন AI নতুন ফিচার জেনারেট করে, সেরা ফলাফল হল: এটি একবার ডোমেইন নিয়ম আপডেট করে, এবং প্রতিটি ক্লায়েন্ট স্বয়ংক্রিয়ভাবে লাভবান হয়।

কী আলাদা থাকা উচিত

কিছু কোড শক্তভাবে শেয়ার করা ঝুঁকিপূর্ণ বা ব্যয়বহুল:

• UI কম্পোনেন্ট: ওয়েব ডিজাইন সিস্টেম বনাম নেটিভ কন্ট্রোল
• নেভিগেশন ও ইউজার ফ্লো: ব্রাউজার রাউটিং বনাম মোবাইল স্ট্যাক
• ডিভাইস ক্ষমতা: পুশ নোটিফিকেশন, বায়োমেট্রিক্স, ক্যামেরা, অফলাইন স্টোরেজ

প্রায়োগিক নিয়ম: যদি ব্যবহারকারী এটি দেখতে পারে বা OS এটি ভাঙতে পারে, তাহলে এটি অ্যাপ-নির্দিষ্ট রাখুন। যদি এটি ব্যবসায়িক সিদ্ধান্ত হয়, ডোমেইনে রাখুন।

লেয়ার অনুযায়ী দায়িত্ব

• API লেয়ার: অথেনটিকেশন, রেট লিমিট, HTTP/GraphQL থেকে ডোমেইন কমান্ডে ম্যাপিং।
• ডোমেইন লেয়ার: পিউর নিয়ম এবং ইউজ—কেস, মিনিমাল ডিপেন্ডেন্সি সহ।
• ডাটা সোর্স: DB এবং থার্ড-পার্টি সার্ভিসগুলো ইন্টারফেসের পিছনে রাখা যাতে ইমপ্লিমেন্টেশন বদলালে ব্যবসায়িক লজিক রিরাইট না করতে হয়।

শেয়ার্ড ডোমেইন লেয়ার (ব্যবসায়িক লজিক)

শেয়ার্ড ডোমেইন লেয়ার হলো সেই অংশ যা “নির্বিকার” হওয়া উচিত: পূর্বানুমেয়, টেস্টযোগ্য, এবং প্রতিটি জায়গায় পুনব্যবহারযোগ্য। যদি AI আপনার সিস্টেম তৈরিতে সাহায্য করে, এই লেয়ারটাই প্রকল্পের অর্থকে ল্যাঞ্চ করে—তাই ওয়েব স্ক্রিন, মোবাইল ফ্লো, এবং API এন্ডপয়েন্ট সব একই নিয়ম প্রতিফলিত করে।

শুরু করুন নামপদ এবং ক্রিয়াগুলো দিয়ে

আপনার পণ্যের মূল ধারণাগুলো সংজ্ঞায়িত করুন এনটিটি (পরিচয়সম্পন্ন বস্তু: Account, Order, Subscription) এবং ভ্যালু অবজেক্ট (ভ্যালু দ্বারা সংজ্ঞায়িত: Money, EmailAddress, DateRange) হিসেবে। তারপর আচরণগুলো ক্যাপচার করুন ইউজ—কেস (অ্যাপ্লিকেশন সার্ভিস): “Create order”, “Cancel subscription”, “Change email” ইত্যাদি।

এই স্ট্রাকচার ডোমেইনটিকে নন-স্পেশালিস্টদের জন্যও বোধগম্য রাখে: নামপদগুলি কী আছে বলে, ক্রিয়াগুলো কী করে বলে।

ব্যবসায়িক নিয়ম UI-অ্যাগনস্টিক রাখুন

ডোমেইন লজিকে জানা উচিত না এটি কোন ট্রিগার করেছে—বাটন ট্যাপ, ওয়েব ফর্ম সাবমিশন, না API অনুরোধ। বাস্তবে এর মানে:

• কোন ফ্রেমওয়ার্ক ইম্পোর্ট নেই (ডোমেইনে ওয়েব কন্ট্রোলার, মোবাইল ভিউ, বা ORM অ্যানোটেশন নেই)
• UI স্ট্রিং নেই (এর বদলে এরর কোড বা কী ব্যবহার করুন)
• নেটওয়ার্ক অনুমান নেই (ডোমেইন “API কল” করে না; নিয়ম প্রকাশ করে)

যখন AI কোড জেনারেট করে, এই বিভাজন হারানো সহজ—মডিউলগুলো UI কনসার্ন দিয়ে ভর্তি হয়ে যেতে পারে। একে রিফ্যাক্টর করার নির্দেশনা হিসেবে নিন, পছন্দ হিসেবে নয়।

সব জায়গায় একই ভ্যালিডেশন সেট রাখুন

ভ্যালিডেশনেই প্রায়ই ড্রিফট দেখা যায়: ওয়েব কিছু দেয় যা API প্রত্যাখ্যান করে, বা মোবাইল আলাদা ভ্যালিডেশন করে। ভ্যালিডেশনকে ডোমেইন লেয়ার (বা একটি শেয়ার্ড ভ্যালিডেশন মডিউল)-এ রাখুন যাতে সব সারফেস একই নিয়ম প্রয়োগ করে।

উদাহরণ:

• EmailAddress একবার ফরম্যাট যাচাই করে, ওয়েব/মোবাইল/API সবখানে reused
• Money নেগেটিভ টোটাল ঠেকায়, যেখান থেকেই মান এসেছে তা নির্বিশেষে
• ইউজ—কেস ক্রস-ফিল্ড নিয়ম এনফোর্স করে (উদা: “end date must be after start date”)

এটি ভালভাবে করলে, API লেয়ার হয় একজন অনুবাদক, আর ওয়েব/মোবাইল হয় প্রেজেন্টার—ডোমেইন লেয়ারই একমাত্র সত্যের উৎস থাকে।

API লেয়ার: কনট্র্যাক্ট যা বাকি সবকিছুকে চালায়

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

API-ফার্স্ট কনট্র্যাক্ট দিয়ে শুরু করুন

কনট্র্যাক্ট জেনারেট করার আগে সংজ্ঞায়িত করুন:

• এন্ডপয়েন্ট এবং রিসোর্স: একরকম নামপদ (উদাহরণ /users, /orders/{id}), পূর্বানুমেয় ফিল্টারিং ও সোর্টিং।
• এরর: স্থিতিশীল এরর শেপ (code, message, details) এবং HTTP স্ট্যাটাস ব্যবহার নথিভুক্ত করুন।
• পেজিনেশন: একটি পদ্ধতি নির্বাচন করুন (ক্যার্সার-ভিত্তিক সহজে বিবর্তনযোগ্য) এবং রেসপন্স ফিল্ড স্ট্যান্ডার্ডাইজ করুন।
• ভার্সনিং: আগে থেকে সিদ্ধান্ত নিন (পাথ /v1/... বা হেডার-ভিত্তিক) এবং ডিপ্রিকেশনের নিয়ম নথিভুক্ত করুন।

এক স্কিমা থেকে টাইপ ও ক্লায়েন্ট জেনারেট করুন

OpenAPI (বা GraphQL SDL-এর মতো স্কিমা-ফার্স্ট টুল) কে ক্যাননিকাল আর্টিফ্যাক্ট হিসেবে ব্যবহার করুন। সেখান থেকে জেনারেট করুন:

• সার্ভার স্টাব (রুট, ভ্যালিডেশন স্ক্যাফোল্ড)
• টাইপড ক্লায়েন্ট ওয়েব ও মোবাইলের জন্য
• শেয়ার্ড রিকোয়েস্ট/রেসপন্স মডেল যা ড্রিফট কমায়

এটি AI-উৎপাদিত কোডের জন্য জরুরি: মডেল দ্রুত কোড তৈরি করতে পারে, কিন্তু স্কিমাই এটাকে সঙ্গত রাখে।

সূক্ষ্ম ভাঙ্গন প্রতিরোধের নিয়ম

কয়েকটি অমি-নেগোশিয়েবল নীতি নির্ধারণ করুন:

• নামকরণ: snake_case না হলে camelCase; উভয় নয়; JSON ও জেনারেটেড টাইপসের মধ্যে মিল রাখুন।
• স্ট্যাটাস কোড: সফলতার জন্য 200/201/204; ভ্যালিডেশনের জন্য 400; অথরাইজেশনের জন্য 401/403; কনফ্লিক্টের জন্য 409।
• আইডেম্পোটেনসি: ঝুঁকিপূর্ণ অপারেশনের জন্য Idempotency-Key প্রয়োজন করুন (পেমেন্ট, অর্ডার তৈরি) এবং রিট্রাই আচরণ সংজ্ঞায়িত করুন।

API কনট্র্যাক্টকে পণ্যের মত আচরণ করুন। যখন এটি স্থিতিশীল, বাকি সবকিছু জেনারেট, টেস্ট, এবং শিপ করা সহজ হয়ে যায়।

ওয়েব অ্যাপ: শেয়ার্ড লজিক ইন্টিগ্রেট করা ছাড়া কাপলিং এড়ান

ওয়েব অ্যাপ শেয়ার্ড ব্যবসায়িক লজিক থেকে অনেক সুবিধা পায়—এবং কষ্ট পায় যখন সেই লজিক UI কনসার্নের সাথে জড়িয়ে পড়ে। মূলনীতি হল শেয়ার্ড ডোমেইন লেয়ারকে “হেডলেস” ইঞ্জিন হিসেবে বিবেচনা করা: এটি নিয়ম, ভ্যালিডেশন, এবং ওয়ার্কফ্লো জানে, কিন্তু কম্পোনেন্ট, রুট, বা ব্রাউজার API সম্পর্কে কিছুই জানে না।

রেন্ডারিং পছন্দ: SSR বনাম CSR (এবং কেন এটি গুরুত্বপূর্ণ)

যদি আপনি SSR (server-side rendering) ব্যবহার করেন, শেয়ার্ড কোড সার্ভারে চলার জন্য সেফ হতে হবে: সরাসরি window, document, বা ব্রাউজার স্টোরেজ কল করা যাবে না। এটি একটি ভালো জোরালো পদ্ধতি: ব্রাউজার-নির্ভর আচরণকে একটি পাতলা ওয়েব অ্যাডাপ্টার লেয়ারে রাখুন।

CSR (client-side rendering)-এ আপনি বেশি স্বাধীনতা পাবেন, কিন্তু একই ডিসিপ্লিন এখনও কার্যকর। CSR-মাত্রা প্রকল্পগুলো প্রায়ই “অকস্মাৎ” UI কোডকে ডোমেইনে ইমপোর্ট করে কারণ সবকিছু ব্রাউজারে চলে—পরবর্তীতে SSR, edge rendering, বা Node-এ চলা টেস্ট যোগ করলে সমস্যা দেখা দেয়।

প্রায়োগিক নিয়ম: শেয়ার্ড মডিউলগুলো ডিটারমিনিস্টিক এবং পরিবেশ-অ্যাগনস্টিক হওয়া উচিত; কুকি, localStorage, বা URL-কে স্পর্শ করা কিছুই ওয়েব অ্যাপ লেয়ারে থাকুক।

স্টেট বাউন্ডারি: ডোমেইন স্টেট বনাম UI স্টেট

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

এটি React/Vue স্টেট ব্যবস্থাপনাকে নমনীয় রাখে: লাইব্রেরি বদলালে ব্যবসায়িক নিয়মগুলো পুনরায় লেখার দরকার পড়বে না।

ওয়েব-নির্দিষ্ট বিষয়গুলো আলাদা করুন

ওয়েব লেয়ারটি নিম্নলিখিত হ্যান্ডেল করা উচিত:

• অ্যাক্সেসিবিলিটি (সেমান্টিক মার্কআপ, কীবোর্ড ন্যাভিগেশন, ARIA)
• রাউটিং (URL স্ট্রাকচার, ডিপ লিংক, সার্ভার রিডাইরেক্ট)
• ব্রাউজার স্টোরেজ (কুকি/সেশন, localStorage, ক্যাশিং)

ওয়েব অ্যাপটিকে একটি অ্যাডাপ্টার হিসেবে ভাবুন: এটি ইউজার ইন্টার‌অ্যাকশনকে ডোমেইন কমান্ডে অনুবাদ করে—আর ডোমেইন আউটকামকে অ্যাক্সেসিবল স্ক্রিনে রূপান্তর করে।

মোবাইল অ্যাপ: নেটিভ ক্ষমতাসহ শেয়ার্ড লজিক

মোবাইল অ্যাপ শেয়ার্ড ডোমেইন লেয়ার থেকে সবচেয়ে বেশি সুবিধা পায়: মূল্যনীতি, যোগ্যতা, ভ্যালিডেশন, এবং ওয়ার্কফ্লো ফিচারগুলো ওয়েব ও API-র মতোই আচরণ করা উচিত। মোবাইল UI তারপর সেই শেয়ার্ড লজিককে ঘিরে একটি “শেল” হয়ে ওঠে—টাচ-উপযোগী, অনিয়মিত কানেক্টিভিটির উপযোগী, এবং ডিভাইস ফিচারগুলো ব্যবহার করে অপ্টিমাইজ করা।

প্ল্যাটফর্ম প্যাটার্নগুলো ডিজাইন করুন

শেয়ার্ড ব্যবসায়িক লজিক থাকলেও মোবাইলের প্যাটার্নগুলো সচরাচর ওয়েবের সাথে 1:1 মিলবে না:

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

অফলাইন-ফার্স্ট: ক্যাশ, সিঙ্ক, এবং কনফ্লিক্ট কৌশল

যদি বাস্তব মোবাইল ব্যবহার আশা করেন, অফলাইনকে অনুমান করুন:

• লোকালি রিড মডেল ক্যাশ করুন (কি-ভ্যালু বা SQLite) স্পষ্ট স্ট্যালনেস পলিসি সহ।
• রাইটগুলোকে ইন্টেন্ট/ইভেন্ট হিসেবে কিউ করুন (উদা: “অর্ডার ড্রাফট তৈরি”), তারপর অনলাইনে এসে সিঙ্ক করুন।
• কনফ্লিক্ট রুল আগেই নির্ধারণ করুন (লাস্ট-রাইট-উইন, সার্ভার-অথরিটেটিভ মার্জ, বা ইউজার রেজোলিউশন)।
• API নিরাপদে ডুপ্লিকেট গ্রহণ করতে পারে এমনভাবে রিট্রাই+আইডেম্পোটেনসি কী বাস্তবায়ন করুন।

মোবাইল-নির্দিষ্ট চিন্তা

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

সব সারফেসে ডেটা মডেল, অথ, এবং পারমিশন

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

ডেটা মডেলের জন্য একটি উৎস রাখুন

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

• স্কিমা-ফার্স্ট: স্কিমা ফাইলগুলোতে এন্টিটি ও ভ্যালিডেশন নির্ধারণ করুন (OpenAPI/JSON Schema), তারপর API, ওয়েব, মোবাইলের জন্য টাইপ জেনারেট করুন।
• শেয়ার্ড মডিউল: মডেল টাইপ এবং ভ্যালিডেটরগুলো শেয়ার্ড প্যাকেজে রাখুন যা সব অ্যাপ ইমপোর্ট করে।
• হাইব্রিড: এক্সটার্নাল কনট্র্যাক্টের জন্য স্কিমা ফাইল, ইন্টারনাল ডোমেইন নিয়মের জন্য শেয়ার্ড মডিউল।

টুলটি কী নয়—সমঞ্জস্যতা গুরুত্বপূর্ণ। যদি “OrderStatus” এক ক্লায়েন্টে পাঁচ মান থাকে আর অন্যটিতে ছয়, AI-উৎপাদিত কোড সুশৃঙ্খল কম্পাইল হলেও বাগ নিয়ে যাবে।

অথেনটিকেশন: সেশন, টোকেন, এবং সিকিউর স্টোরেজ

অথেনটিকেশন ব্যবহারকারীর কাছে একই অনুভূতি দিতে পারে, কিন্তু প্রযুক্তিগত বাস্তবায়ন সারফেসভেদে আলাদা হয়:

• ওয়েব সাধারণত কুকি-ভিত্তিক সেশন পছন্দ করে (CSRF রোধে সুবিধা, ব্রাউজার স্টোরেজ সহজ)।
• মোবাইল ও তৃতীয়-পক্ষ ক্লায়েন্ট সাধারণত টোকেন-ভিত্তিক অথ চায় (অ্যাক্সেস + রিফ্রেশ টোকেন)।

একটি একক ফ্লো ডিজাইন করুন: লগইন → স্বল্প-জীবী অ্যাক্সেস → প্রয়োজন হলে রিফ্রেশ → সার্ভার-সাইড স্টেট অব্যাহত রেখে লগআউট। মোবাইল-এ সিকিউর স্টোরেজে (Keychain/Keystore) সিক্রেট রাখুন; ওয়েব-এ httpOnly কুকি ব্যবহার করুন যাতে টোকেন JS-এ প্রকাশ না পায়।

অথরাইজেশন: কেন্দ্রীভূত নিয়ম, API-এ এনফোর্স

পারমিশন একবার সংজ্ঞায়িত করুন—সর্বোৎকৃষ্টভাবে ব্যবসায়িক নিয়মের কাছে—তারপর সব জায়গায় প্রয়োগ করুন:

• কেন্দ্রীভূত চেক ডোমেইন লেয়ারে রাখুন (উদা: canApproveInvoice(user, invoice))।
• API-তে তাদের এনফোর্স করুন বাস্তব নিরাপত্তার জন্য।
• UI-তে কেবল দেখানো/অদৃশ্য করা যাতে অ্যাকশন লুকিয়ে বা নিষ্ক্রিয় করা যায়, কিন্তু ডেটা নিরাপদ না’বলা যায়নি।

এটি “মোবাইল কাজ করে কিন্তু ওয়েবে না” ড্রিফট প্রতিরোধ করে এবং AI কোড জেনারেশনকে কে পারবে কি তা টেস্টেবল কনট্র্যাক্ট দেয়।

বিল্ড, রিলিজ, এবং ডিপ্লয়মেন্ট কৌশল

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

মনোরেপো বনাম মাল্টি-রেপো

একটি মনোরেপো (একটি রিপো, একাধিক প্যাকেজ/অ্যাপ) সাধারণত একটি একক কোডবেসের জন্য ভাল কাজ করে কারণ শেয়ার্ড ডোমেইন লজিক, API কনট্র্যাক্ট, এবং UI ক্লায়েন্টগুলো একসঙ্গে উন্নত হয়। আপনি অ্যাটমিক চেঞ্জ পাবেন (একটি PR এ একটি কন্ট্র্যাক্ট ও সব কনসিউমার আপডেট) এবং সহজ রিফ্যাক্টর।

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

বিল্ড টার্গেট ও আর্টিফ্যাক্ট

প্রতিটি সারফেসকে আলাদা বিল্ড টার্গেট হিসেবে বিবেচনা করুন যা শেয়ার্ড প্যাকেজগুলো খায়:

• API সার্ভিস আর্টিফ্যাক্ট: কন্টেইনার ইমেজ বা সার্ভারলেস বান্ডেল
• ওয়েব বাণ্ডেল: স্ট্যাটিক অ্যাসেট + সার্ভার রUNTIME (যদি SSR)
• মোবাইল বিল্ড: Android (AAB/APK) এবং iOS (IPA) নেটিভ পাইপলাইন দ্বারা উৎপাদিত, শেয়ার্ড লজিককে ডিপেন্ডেন্সি হিসেবে টেনে নিয়ে

বিল্ড আউটপুট এক্সপ্লিসিট এবং রেপ্রোডিউসিবল রাখুন (লকফাইল, পিন্ড টুলচেইন, ডিটারমিনিস্টিক বিল্ড)।

CI/CD পাইপলাইন এবং পরিবেশ পৃথকীকরণ

একটি টিপিক্যাল পাইপলাইন: lint → typecheck → unit tests → contract tests → build → security scan → deploy।

কনফিগ কোড থেকে আলাদা রাখুন: এনভায়রনমেন্ট ভেরিয়েবল এবং সিক্রেটগুলো আপনার CI/CD এবং সিক্রেট ম্যানেজারে রাখুন, রিপোতে নয়। dev/stage/prod ওভারলে ব্যবহার করুন যাতে একই আর্টিফ্যাক্ট বাই-আরও পরিবেশে পুনঃপ্রচার করা যায়—বিশেষ করে API এবং ওয়েব রানটাইমের জন্য।

শেয়ার্ড কোডের জন্য টেস্টিং ও কোয়ালিটি গেট

ওয়েব, মোবাইল, এবং API এক সাথে শিপ করলে টেস্টিং আর একটি ‘‘আরও একটি চেকবক্স’’ নয়—এটি সেই মেকানিজম যা ছোট পরিবর্তনকে তিনটি প্রোডাক্টকে ভাঙতে দেয় না। লক্ষ্যটি সহজ: সমস্যা সস্তায় খুঁজে বের করুন, এবং ঝুঁকিপূর্ণ পরিবর্তনগুলো ব্যবহারকারীর কাছে পৌঁছানোর আগে বাধা দিন।

শেয়ার্ড কোডবেসের জন্য বাস্তবিক টেস্ট পিরামিড

শেয়ার্ড ডোমেইন (ব্যবসায়িক লজিক) দিয়ে শুরু করুন কারণ সেটি সবচেয়ে পুনর্ব্যবহৃত এবং ইনফ্রাসট্রাকচার ছাড়াই টেস্ট করত সহজ।

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

এই স্ট্রাকচারটি বেশিরভাগ কনফিডেন্স ডোমেইন লজিকে রাখে, আবার লেয়ার সংযোগস্থলে “ওয়্যারিং” সমস্যাগুলো ধরা পড়ে।

কনট্র্যাক্ট টেস্টিং যাতে ক্লায়েন্ট ও API সারিবদ্ধ থাকে

মনোরেপোতেও, API এমনভাবে পরিবর্তিত হতে পারে যে কম্পাইল হয় কিন্তু ইউজার অভিজ্ঞতা ভাঙে। কনট্র্যাক্ট টেস্টগুলি নীরব ড্রিফট প্রতিরোধ করে।

• API-টু-ক্লায়েন্ট কনট্র্যাক্ট: রিকোয়েস্ট/রেসপন্স শেপ, এরর ফরম্যাট, এবং স্ট্যাটাস কোড লক করুন। যদি API নতুন রিকোয়ার্ড ফিল্ড রিটার্ন করে বা একটি এনাম মান বদলে, কনট্র্যাক্ট টেস্ট CI-তে ফেল করবে।
• স্কিমা গেট হিসেবে: OpenAPI/GraphQL স্কিমা প্রকাশ করলে স্কিমা পরিবর্তনকে রিভিউযোগ্য আর্টিফ্যাক্ট হিসেবে বিবেচনা করুন। ব্রেকিং চেঞ্জ স্পষ্ট অনুমোদন এবং মাইগ্রেশন প্ল্যান ছাড়া করা যাবে না।

রিলিজ সুরক্ষার গেট

ভাল টেস্ট গুরুত্বপূর্ণ, কিন্তু তাদের চারপাশের নিয়মও তেমনই গুরুত্বপূর্ণ।

• পুল রিকওয়েস্ট গেট: ইউনিট + ইন্টিগ্রেশন টেস্ট, লিন্ট/ফরম্যাটিং, এবং ডোমেইন লেয়ারের মিনিমাম কভারেজ পাস বাধ্যতামূলক করুন।
• ফিচার ফ্ল্যাগ: অর্ধ-complete আচরণ গোপনে শিপ করুন যে ভাবে নির্দিষ্ট এনভায়রনমেন্ট বা ইউজার গ্রুপে চালু করা যায়।
• স্টেজড রোলআউট: প্রথমে ইন্টারনাল ইউজার, তারপর প্রোডাকশনের ক্ষুদ্র শতাংশ, তারপর সবার কাছে রিলিজ।
• রোলব্যাক প্ল্যান: রোলব্যাককে প্রথম-শ্রেণীর ফলাফল বানান—ভার্সনড রিলিজ, ডেটাবেস মাইগ্রেশন যা reverible বা নিরাপদে ফরওয়ার্ড করা যায়, এবং স্পষ্ট “স্টপ দ্য লাইন” মানদণ্ড।

এই গেটগুলো থাকলে AI-সহায়ত পরিবর্তনগুলো ঘন হলেও ভঙ্গুর হয় না।

আর্কিটেকচার নিয়ন্ত্রণ হারিয়ে না ফেলেই AI ব্যবহার কিভাবে করবেন

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

AI কোথায় সবচেয়ে সাহায্য করে (এবং কম ঝুঁকিপূর্ণ)

AI ব্যবহার করুন সেই “ফার্স্ট ভার্সন” তৈরিতে যেগুলো আপনি মেকানিক্যালভাবে লিখতেন:

• প্রজেক্ট স্ক্যাফোল্ড (ফোল্ডার, বয়লারপ্লেট মডিউল, ফিচার স্কেলেটন)
• বিদ্যমান কনট্র্যাক্ট থেকে API ডকস এবং উদাহরণ
• টেস্ট স্যুট (ডোমেইন নিয়মের চারপাশে ইউনিট টেস্ট, এন্ডপয়েন্টের কনট্র্যাক্ট টেস্ট)
• মাইগ্রেশন এবং সিড ডেটা স্ক্রিপ্ট
• পুনরাবৃত্ত রিফ্যাক্টর (ফিল্ড রিনেম, মডিউল বিভক্ত করা), পরিকল্পনা নির্ধারণের পরে

একটি ভাল নিয়ম: AI কোড এমনভাবে উৎপাদন করুক যে পড়া বা টেস্ট চালিয়ে যাচাই করা সহজ হয়—না এমন কোড যেটা চুপচাপ ব্যবসায়িক অর্থ বদলে দেয়।

আর্কিটেকচার রক্ষা করার গার্ডরেইল

AI আউটপুটকে স্পষ্ট নিয়ম দ্বারা সীমাবদ্ধ করুন, মুড দ্বারা নয়। এই নিয়মগুলো কোডেই রাখুন:

• কোডিং স্ট্যান্ডার্ড: লিন্টার/ফরম্যাটার, নামকরণ নিয়ম, এবং “UI থেকে সরাসরি DB অ্যাক্সেস নয়” স্টাইল কনস্ট্রেইন্ট।
• আর্কিটেকচারাল নিয়ম: ডিপেন্ডেন্সি বাউন্ডারি (ডোমেইন লেয়ার API/ওয়েব/মোবাইল ইমপোর্ট করতে পারবে না), টুলিং বা বিল্ড চেক দিয়ে এনফোর্স করুন।
• PR চেকলিস্ট: “কনট্র্যাক্ট বদলেছে? OpenAPI + ক্লায়েন্ট টাইপ আপডেট করুন + টেস্ট আপডেট করুন।” “নতুন ডোমেইন নিয়ম? ডোমেইন টেস্ট যোগ করুন।”

AI যদি এমন শর্টকাট প্রস্তাব করে যা বাউন্ডারি ভাঙে, উত্তর হবে “না”, এমনকি যদি তা কম্পাইল করে।

গভর্ন্যান্স: AI কাজকে অডিটযোগ্য করে রাখুন

ঝুঁকি কেবল খারাপ কোড নয়—ট্র্যাক করা না হওয়া ডিসিশনও। একটি অডিট ট্রেইল রাখুন:

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

AI সবচেয়ে মূল্যবান হয় যখন এটি পুনরাবৃত্তিযোগ্য: টিম দেখতে পারে কেন কিছু জেনারেট হয়েছে, যাচাই করতে পারে, এবং যখন দরকার পুনরায় সুরক্ষিতভাবে জেনারেট করতে পারে।

টুলিং নোট: সীমাবদ্ধতা মান্য করে এমন AI

যদি আপনি সিস্টেম-পর্যায়ে AI-সহায়তা গ্রহণ করেন (ওয়েব + API + মোবাইল), সবচেয়ে গুরুত্বপূর্ণ “ফিচার” কাঁচামাল জেনারেশনের গতি নয়—এটি আউটপুটগুলোকে আপনার কন্ট্র্যাক্ট ও লেয়ারিং-এর সাথে সামঞ্জস্য রাখার ক্ষমতা।

উদাহরণস্বরূপ, Koder.ai একটি ভিব-কোডিং প্ল্যাটফর্ম যা টিমগুলোকে চ্যাট ইন্টারফেসের মাধ্যমে ওয়েব, সার্ভার, এবং মোবাইল অ্যাপ তৈরি করতে সাহায্য করে—তারপরও বাস্তব, এক্সপোর্টযোগ্য সোর্স কোড উৎপাদন করে। ব্যবহারিকভাবে, এটি এই আর্টিকেলে বর্ণিত ওয়ার্কফ্লোরের জন্য উপযোগী: আপনি একটি API কন্ট্র্যাক্ট ও ডোমেইন নিয়ম সংজ্ঞায়িত করে দ্রুত React-ভিত্তিক ওয়েব সারফেস, Go + PostgreSQL ব্যাকএন্ড, এবং Flutter মোবাইল অ্যাপ ইটারেট করতে পারেন আর্কিটেকচার বাউন্ডারিগুলো হারানোর ঝুঁকি ছাড়াই। প্ল্যানিং মোড, স্ন্যাপশট, এবং রোলব্যাকের মতো ফিচারগুলোও “জেনারেট → যাচাই → প্রোমোট” রিলিজ ডিসিপ্লিনের সাথে ভালোভাবে মানানসই।

কখন একক কোডবেস ব্যবহার করা ঠিক নয় (এবং বিকল্প কী)

একক কোডবেস ডুপ্লিকেশন কমাতে পারে, কিন্তু এটি সর্বদা “সেরা” পছন্দ নয়। যেই মুহূর্তে শেয়ার করা কোড অদক্ষ UX চাপিয়ে দেয়, রিলিজ ধীর করে, বা প্ল্যাটফর্ম পার্থক্য লুকায়, তখন আপনি আর্কিটেকচার নিয়ে আলোচনায় বেশি সময় ব্যয় করবেন অভাবে ভ্যালু শিপ করার পরিবর্তে।

আলাদা কোডবেস যখন ভাল

আলাদা কোডবেস (অন্তত আলাদা UI লেয়ার) প্রায়শই উপযুক্ত যখন:

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

সাধারণ ব্যর্থতার মোড

• ওভার-শেয়ারিং UI: “একই UI সব কিছুকে শাসন করবে” মানে ন্যূনতম-সামঞ্জস্যপূর্ণ অভিজ্ঞতা।
• লিকি অ্যাবস্ট্রাকশন: একটি “শেয়ারড” মডিউল এখনও ওয়েব/মোবাইল ডিটেইল উন্মোচন করে (রাউটিং, স্টোরেজ, অথ টোকেন), ফলে প্রতিটি কনসিউমার ভঙ্গুর হয়ে যায়।
• সংস্করণ ড্রিফট: টিমগুলো দ্রুততা পেতে কপি-পেস্ট করে শেয়ারড কোড কপি করে, তারপর ফিক্স এক জায়গায় ল্যান্ড করে আর অন্য জায়গায় না।

সিদ্ধান্ত চেকলিস্ট (এবং বিকল্প)

একটি একক কোডবেস নিশ্চিত করার আগে জিজ্ঞাসা করুন:

• ডোমেইন লজিক কি পরিষ্কারভাবে শেয়ার করা যায় যখন UI নেটিভ থাকবে?
• প্ল্যাটফর্ম টিমগুলো কি টুলিং, রিলিজ সময়সূচি, এবং পরীক্ষা-নির্বাহে স্বায়ত্তশাসন প্রয়োজন?
• API কি পর্যাপ্ত স্থিতিশীল যাতে ক্লায়েন্ট স্বাধীনভাবে বিবর্তিত হতে পারে?

যদি সতর্ক সংকেত দেখা দেয়, একটি ব্যবহারিক বিকল্প হলো শেয়ার্ড ডোমেইন + API কন্ট্র্যাক্ট, কিন্তু অলাদা ওয়েব ও মোবাইল অ্যাপ। শেয়ার্ড কোডকে ব্যবসায়িক নিয়ম ও ভ্যালিডেশনে সীমাবদ্ধ রাখুন, এবং প্রতিটি ক্লায়েন্টকে UX ও প্ল্যাটফর্ম ইন্টিগ্রেশনের মালিক রাখুন।

যদি আপনি পথ নির্বাচন করতে সহায়তা চান, /pricing দেখে বিকল্প তুলনা করুন অথবা সম্পর্কিত আর্কিটেকচার প্যাটার্নগুলো /blog-এ ব্রাউজ করুন।