Architecture pattern — MVC, MVVM, layered আর monolith বনাম service

১ · Separation of concerns — রেস্তোরাঁয় কেন একজনই সব করেন না

বাজারঘর নামের কাল্পনিক অনলাইন দোকানটি আমরা এই কোর্স জুড়ে বানাব। ধরুন প্রথম সপ্তাহেই একটি মাত্র ফাংশনে “কার্টে যোগ করুন” লিখে ফেললেন। সেই ফাংশন request পড়ে, stock দেখে, দাম হিসাব করে, database-এ লেখে, আবার HTML-ও বানায়। প্রথম দিন সব ঠিকঠাক চলে।

তিন মাস পরে তিনটি বদল এলো। মালিক বললেন, ঈদে ছাড় দিতে হবে। ডিজাইনার বললেন, পাতার চেহারা বদলাবে। আপনি ঠিক করলেন, database বদলাবেন। তিনটি বদলের জন্যই ওই একই ফাংশন খুলতে হচ্ছে। একটি বদল করতে গিয়ে আরেকটি ভাঙছে। এটাই architecture-এর আসল সমস্যা। Architecture মানে কোড কোথায় থাকবে, কে কাকে চিনবে, আর কোন বদল কতটুকু কোড ছোঁবে — এই সিদ্ধান্তগুলো।

একটি সতর্কতা শুরুতেই। Pattern কোনো ধর্ম নয়। পঞ্চাশ লাইনের script-এ চার স্তর বানালে সেটি উল্টো বোঝা। Pattern একটি দাম, যা দিয়ে ভবিষ্যতের সহজ বদল কেনা হয়। তাই প্রতিটি pattern-এর সাথে আমরা দামটিও দেখব।

২ · MVC — desktop থেকে web-এ এসে অর্থ বদলাল

MVC (Model-View-Controller) সবচেয়ে পুরোনো আর সবচেয়ে বেশি ভুল বোঝা pattern. তিনটি ভাগ এমন: model হলো data আর তার নিয়ম, view হলো যা দেখানো হয়, controller হলো ব্যবহারকারীর কাজ গ্রহণ করে বাকি দুজনকে চালানোর অংশ।

Desktop-এর মূল MVC-তে view আর model একই কম্পিউটারে, একই সময়ে বেঁচে থাকে। Model বদলালে সে নিজে সব view-কে খবর দেয় (observer), আর view নিজেকে আঁকে। ওয়েবে এটি অসম্ভব। Browser আর server আলাদা, HTTP-তে server নিজে থেকে পাতা বদলাতে পারে না। তাই ১৯৯০-এর দশকের শেষে Java-র জগৎ থেকে একটি রূপান্তরিত নকশা আসে, আর Rails (২০০৪) সেটিকে বিখ্যাত করে।

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

GET /products/1 HTTP/1.1
Host: bazarghar.example

pattern:  /products/:id
id:       "1"
ডাকবে:    ProductController.show

id = Number("1")   // 1
ProductModel.find(1)

SELECT id, name, taka, stock FROM products WHERE id = $1
-- $1 = 1
{ id: 1, name: "Chal 5kg", taka: 420, stock: 3 }

<h1>Chal 5kg</h1><p>420 taka, in stock</p>

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Chal 5kg</h1><p>420 taka, in stock</p>

এবার একই গঠন নিজে চালিয়ে দেখুন। কোনো framework নেই, শুধু তিনটি অংশ আর একটি ছোট router. কোড বদলে নতুন ঠিকানা বা নতুন পণ্য যোগ করতে পারেন।

// Model: data আর তা খোঁজার নিয়ম। HTTP বা HTML চেনে না।
const ProductModel = {
  rows: [
    { id: 1, name: "Chal 5kg", taka: 420, stock: 3 },
    { id: 2, name: "Dal <b>sale</b>", taka: 140, stock: 0 },
  ],
  find(id) { return this.rows.find((r) => r.id === id) ?? null; },
};

// View: data থেকে লেখা। কোনো সিদ্ধান্ত data বদলায় না।
const esc = (s) => String(s).replace(/&/g, "&amp;").replace(/</g, "&lt;");
const ProductView = {
  page: (p) => `<h1>${esc(p.name)}</h1><p>${p.taka} taka, ` +
    `${p.stock > 0 ? "in stock" : "stock out"}</p>`,
  notFound: (id) => `<h1>404</h1><p>No product ${id}</p>`,
};

// Controller: দুজনকে জোড়ে।
function show(id) {
  const product = ProductModel.find(id);
  if (!product) return { status: 404, html: ProductView.notFound(id) };
  return { status: 200, html: ProductView.page(product) };
}

// Router: ঠিকানা থেকে controller.
function handle(url) {
  const m = url.match(/^\/products\/(\d+)$/);
  return m ? show(Number(m[1])) : { status: 404, html: "<h1>No route</h1>" };
}

for (const url of ["/products/1", "/products/2", "/products/9", "/about"]) {
  const r = handle(url);
  console.log(url, "->", r.status, r.html);
}

/products/1 -> 200 <h1>Chal 5kg</h1><p>420 taka, in stock</p>
/products/2 -> 200 <h1>Dal &lt;b>sale&lt;/b></h1><p>140 taka, stock out</p>
/products/9 -> 404 <h1>404</h1><p>No product 9</p>
/about -> 404 <h1>No route</h1>

৩ · MVP, MVVM আর React — UI = f(state)

Desktop আর মোবাইল UI-তে MVC-র পরে দুটি বড় রূপ আসে। দুটিরই লক্ষ্য view-কে এত পাতলা করা, যাতে পর্দা ছাড়াই আচরণ test করা যায়।

দুইমুখী binding সুবিধার, কিন্তু একটি ঝুঁকি আছে। Screen বড় হলে একটি বদল আরেকটি বদল ঘটায়, সেটি আরেকটি। “এই মানটি কে বদলাল?” প্রশ্নের উত্তর খুঁজতে অনেক জায়গা দেখতে হয়। Facebook-এর দল ২০১৪ সালের দিকে Flux নামে একটি নকশা দেখায়, যেখানে data একদিকেই ঘোরে। এই চিন্তা থেকে পরে Redux (২০১৫) আসে। এর সংক্ষিপ্ত রূপ হিসেবে সম্প্রদায়ে একটি সূত্র বলা হয়: UI = f(state). এটি React-এর কোনো দাপ্তরিক সূত্র নয়, তবে চিন্তাটি পরিষ্কার করে: একই state মানে একই UI.

নিচের ডায়াগ্রামে বাজারঘরের “+” button দুইবার চাপা হচ্ছে। প্রতিটি ধাপে ডান দিকের state আর নিচের UI মিলিয়ে দেখুন।

1function reducer(state, a) {2  if (a.type === 'add') return {3    qty: state.qty + 1, total: state.total + a.taka };4  return state;5}6const view = (s) => `Cart: ${s.qty} / Tk ${s.total}`;7plus.onclick = () => dispatch({ type: 'add', taka: 420 });

একই ধারণা এবার চালানো যায় এমন ছোট store-এ। এখানে বাড়তি একটি জিনিস আছে: state না বদলালে render হয় না।

function createStore(reducer, state) {
  const listeners = [];
  return {
    getState: () => state,
    subscribe: (fn) => listeners.push(fn),
    dispatch(action) {
      const next = reducer(state, action);
      if (next === state) return;          // বদল নেই, render নেই
      state = next;
      listeners.forEach((fn) => fn());
    },
  };
}

function reducer(state, a) {
  if (a.type === "add") return { qty: state.qty + 1, total: state.total + a.taka };
  if (a.type === "clear" && state.qty > 0) return { qty: 0, total: 0 };
  return state;
}

const view = (s) => `Cart: ${s.qty} / Tk ${s.total}`;  // UI = f(state)
const store = createStore(reducer, { qty: 0, total: 0 });

let renders = 0;
const render = () => console.log(`render ${++renders}:`, view(store.getState()));
store.subscribe(render);
render();

const before = store.getState();
store.dispatch({ type: "add", taka: 420 });
store.dispatch({ type: "add", taka: 420 });
store.dispatch({ type: "unknown" });
store.dispatch({ type: "clear" });
store.dispatch({ type: "clear" });
console.log("old state untouched:", before, "| total renders:", renders);

render 1: Cart: 0 / Tk 0
render 2: Cart: 1 / Tk 420
render 3: Cart: 2 / Tk 840
render 4: Cart: 0 / Tk 0
old state untouched: { qty: 0, total: 0 } | total renders: 4

৪ · Layered architecture — controller, service, repository

আজকের বেশিরভাগ backend HTML বানায় না, JSON ফেরত দেয়। তখন MVC-র “view” প্রায় হারিয়ে যায়, আর “model” একা অনেক ভারী হয়ে পড়ে। তাই কাজের নকশাটি হয়েছে layered architecture: তিনটি স্তর, প্রত্যেকটির একটি মাত্র দায়িত্ব।

এবার একই “কার্টে যোগ করুন” দুইভাবে লিখে test করে দেখুন। প্রথমটি জট পাকানো, দ্বিতীয়টিতে নিয়ম আলাদা। Service-কে repository বাইরে থেকে দেওয়া হচ্ছে, এই কৌশলের নাম dependency injection.

const assert = require("node:assert/strict");

// জট পাকানো: HTTP, নিয়ম আর data এক ফাংশনে
const db = { stock: { chal: 3 }, price: { chal: 42000 }, carts: {} };
function tangledHandler(req, res) {
  const { id, qty } = req.body;
  if (qty < 1) return res.status(400).json({ error: "BAD_QTY" });
  if (qty > db.stock[id]) return res.status(409).json({ error: "OUT_OF_STOCK" });
  db.carts[req.user] = { id, qty };
  res.status(201).json({ total: qty * db.price[id] });
}
// test করতে নকল req, নকল res আর আসল db — তিনটিই লাগে
const seen = {};
const fakeRes = { status(c) { seen.code = c; return this; }, json(b) { seen.body = b; } };
tangledHandler({ user: "u1", body: { id: "chal", qty: 2 } }, fakeRes);
console.log("tangled:", seen.code, seen.body, "db.carts:", db.carts);

// স্তরে ভাগ করা: service শুধু নিয়ম জানে, repo বাইরে থেকে আসে
function addItem(repo, user, id, qty) {
  if (qty < 1) throw new Error("BAD_QTY");
  const p = repo.product(id);
  if (qty > p.stock) throw new Error("OUT_OF_STOCK");
  repo.save(user, { id, qty });
  return { total: qty * p.price };
}
// test-এ HTTP নেই, database নেই: নকল repo-ই যথেষ্ট
const saved = [];
const fakeRepo = { product: () => ({ stock: 3, price: 42000 }), save: (u, c) => saved.push(c) };
assert.equal(addItem(fakeRepo, "u1", "chal", 2).total, 84000);
assert.throws(() => addItem(fakeRepo, "u1", "chal", 4), /OUT_OF_STOCK/);
assert.throws(() => addItem(fakeRepo, "u1", "chal", 0), /BAD_QTY/);
console.log("layered: 3 checks passed, saved:", saved.length);

tangled: 201 { total: 84000 } db.carts: { u1: { id: 'chal', qty: 2 } }
layered: 3 checks passed, saved: 1

বাস্তবে একটি controller ভাঙা এক লাফে হয় না। প্রতিটি ধাপে কোড চালু রেখে ধীরে ভাঙতে হয়। নিচের ধাপগুলো দেখুন:

async function addItem(req, res) {
  const { productId, qty } = req.body;
  const p = await db.query('SELECT ... $1', [productId]);
  if (qty > p.stock) return res.status(409).json(...);
  await db.query('INSERT ...', [...]);
  res.status(201).json({ total: qty * p.price });
}

const p = await repo.findProduct(productId);
if (qty > p.stock) return res.status(409).json(...);
await repo.saveItem(userId, productId, qty);

async addItem(userId, productId, qty) {
  const p = await repo.findProduct(productId);
  if (qty > p.stock) throw new CartError('OUT_OF_STOCK');
  await repo.saveItem(userId, productId, qty);
  return { total: qty * p.price };
}

async addItem(req, res) {
  const { productId, qty } = req.body ?? {};
  try {
    const cart = await service.addItem(userId, productId, qty);
    res.status(201).json(cart);
  } catch (e) {
    if (!(e instanceof CartError)) throw e;
    res.status(STATUS[e.code]).json({ error: e.code });
  }
}

await assert.rejects(
  createCartService(fakeRepo(3)).addItem('u1', 'p1', 4),
  { code: 'OUT_OF_STOCK' });

এই নকশা আমরা আসল Express 5.3.0-তে বানিয়ে চালিয়েছি। Service আর test উপরের ধাপের মতো, শুধু বাস্তবের মতো একটু পূর্ণ। সত্যিকারের run (Node 24.15.0, নিজের কম্পিউটারে):

~/bazarghar$ node --test
✔ 2 ta jog korle mot dam 84000 paisa (0.7626ms)
✔ stock-er beshi chaile OUT_OF_STOCK, kichui save hoy na (0.6287ms)
✔ qty 0 hole BAD_QTY (0.1292ms)
ℹ tests 3
ℹ suites 0
ℹ pass 3
ℹ fail 0
…
~/bazarghar$ node src/app.js
201 {"items":[{"productId":"chal-5kg","qty":2,"unitPaisa":42000}],"totalPaisa":84000}
409 {"error":"OUT_OF_STOCK"}
404 {"error":"NOT_FOUND"}
400 {"error":"BAD_QTY"}

Stock 3, প্রথম অনুরোধে 2 নেওয়ার পরে আবার 2 চাইলে মোট 4 হয়, তাই 409. একই service দুই জায়গা থেকে চলল: test থেকে আর HTTP থেকে। পূর্ণ গঠন, dependency injection আর transaction-এর হিসাব পর্ব ২৯ আর পর্ব ৪৩-এ আসবে। এখানে একটি সততা জরুরি: এই কোডে দুজন ক্রেতা একসাথে কিনলে race condition (কোন কাজ আগে শেষ হলো তার ওপর ফল নির্ভর করা) হতে পারে। Layer ভাগ করলে নকশা পরিষ্কার হয়, কিন্তু সব bug চলে যায় না।

৫ · Folder — layer অনুযায়ী, নাকি feature অনুযায়ী

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

src/
  controllers/
    cart.js  order.js
  services/
    cart.js  order.js
  repositories/
    cart.js  order.js

src/features/
  cart/
    cart.routes.js
    cart.controller.js
    cart.service.js
    cart.repository.js
    cart.service.test.js
  order/ …

সাধারণ নিয়ম: প্রায় পাঁচটির বেশি feature হলে বা একাধিক মানুষ কাজ করলে feature folder বেশি সুবিধা দেয়। তবে এটি অভ্যাসের কথা, কোনো মাপা সীমা নয়। Feature-এর ভেতরেও স্তর থাকে; folder শুধু ঠিক করে আগে কী দিয়ে ভাগ হবে। Frontend-এও একই কথা: components/, hooks/ আলাদা না রেখে features/cart/-এ সব রাখা যায়। পর্ব ০৫-এ project-এর পুরো গঠন দেখবেন।

৬ · তিনটি anti-pattern — fat controller, god component, circular dependency

Anti-pattern হলো এমন নকশা, যা শুরুতে সহজ লাগে, পরে দাম চায়। এই তিনটি প্রায় প্রতিটি প্রজেক্টে দেখা যায়।

Circular import শুধু দেখতে খারাপ নয়, এটি সত্যিই প্রোগ্রাম থামাতে পারে। Module-এর নিয়মের জন্য ES modules পর্ব দেখুন। আমরা বাজারঘরে ইচ্ছা করে এমন একটি চক্র বানিয়ে চালালাম: order.js ডাকে payment.js-কে, আর payment.js load হওয়ার সময়েই order.js-এর একটি constant পড়ে। সত্যিকারের run (Node 24.15.0, madge 8.0.0):

~/bazarghar$ node src/cycle/main.js
~/bazarghar/src/cycle/payment.js:2
export const GATEWAY_FEE = DELIVERY_PAISA / 100;
                           ^

ReferenceError: Cannot access 'DELIVERY_PAISA' before initialization
    at ~/bazarghar/src/cycle/payment.js:2:28
…
~/bazarghar$ npx madge --circular src/cycle/main.js
Processed 3 files (370ms)

✖ Found 1 circular dependency!

1) order.js > payment.js

madge হলো import-এর গ্রাফ বানানোর একটি npm টুল। সমাধানও সরল: যে জিনিস দুজনেরই দরকার, সেটি তৃতীয় একটি ফাইলে নিন। DELIVERY_PAISA নতুন pricing.js-তে যাওয়ার পরে চক্র ভাঙল, প্রোগ্রাম 90000 ছাপল, আর একই টুল জানাল No circular dependency found!. এই টুল ভেতরে কী করে? গ্রাফে depth-first search চালায়। ছোট করে নিজেই দেখুন:

const modules = {
  routes: ["cart.controller"],
  "cart.controller": ["cart.service"],
  "cart.service": ["cart.repo", "order.service"],
  "order.service": ["payment.service"],
  "payment.service": ["cart.service", "db"],
  "cart.repo": ["db"],
  db: [],
};
function findCycle(graph) {
  const mark = {};        // "open" = এখনো পথে আছে, "done" = শেষ
  const path = [];
  function visit(name) {
    if (mark[name] === "done") return null;
    if (mark[name] === "open") return [...path.slice(path.indexOf(name)), name];
    mark[name] = "open";
    path.push(name);
    for (const dep of graph[name]) {
      const found = visit(dep);
      if (found) return found;
    }
    path.pop();
    mark[name] = "done";
    return null;
  }
  for (const name of Object.keys(graph)) {
    const found = visit(name);
    if (found) return found;
  }
  return null;
}

console.log("cycle:", findCycle(modules).join(" -> "));
modules["payment.service"] = ["db"];   // payment আর cart.service ডাকে না
console.log("after fix:", findCycle(modules));

cycle: cart.service -> order.service -> payment.service -> cart.service
after fix: null

৭ · Monolith, modular monolith, microservices — সৎ হিসাব

এতক্ষণ কথা ছিল এক প্রোগ্রামের ভেতরের গঠন নিয়ে। এবার প্রশ্ন: পুরো সিস্টেম কয়টি আলাদা চলমান প্রোগ্রাম হবে? এই তিনটি শব্দ আসলে deploy-এর হিসাব, কোডের মান নয়। এলোমেলো monolith যেমন হয়, চমৎকার monolith-ও হয়।

একটি হিসাব — network-এর দাম

ধরুন একটি অর্ডারে পাঁচটি সেবা পরপর লাগে, আর প্রতিটি আলাদাভাবে ৯৯.৯% সময় ঠিক থাকে। ধরে নিচ্ছি একটির ব্যর্থতা আরেকটির ওপর নির্ভর করে না, আর পাঁচটিই না চললে অর্ডার হবে না।

৩০ দিনে ৭২০ ঘণ্টা। একটি সেবা হলে অচল সময় 720 × 0.001 = ০.৭২ ঘণ্টা। পাঁচটি চেইনে হলে 720 × 0.00499 ≈ ৩.৫৯ ঘণ্টা, অর্থাৎ প্রায় পাঁচ গুণ। গতির হিসাবও আছে। একই কম্পিউটারে আমরা একটি ছোট মাপ নিয়েছি: একটি function call গড়ে প্রায় ০.০০০০৫ মিলিসেকেন্ড, আর একই কাজ HTTP দিয়ে (একই কম্পিউটারের ভেতরে, এনক্রিপশন বা database ছাড়া) প্রায় ০.১৪ মিলিসেকেন্ড। অর্থাৎ কয়েক হাজার গুণ। এটি এক কম্পিউটারের এক run, সাধারণ ফল নয়, আর JavaScript ইঞ্জিনের চলার সময়ের optimization ছোট function call-কে আরও ছোট দেখাতে পারে। আসল network-এ দেরি সাধারণত আরও বেশি।

Martin Fowler ২০১৫ সালের Monolith First লেখায় বলেন, তিনি যেসব সফল microservice গল্প শুনেছেন, প্রায় সবই একটি monolith থেকে শুরু। তিনি নিজেই জানান, প্রমাণ এখনো কম আর মতভেদ আছে। সেবার সীমা, Conway-এর সূত্র, strangler fig আর service mesh-এর পূর্ণ আলোচনা আছে Microservices পর্বে। এই পর্বের কাজ শুধু সিদ্ধান্তের ছবিটি দেওয়া।

৮ · BFF আর API gateway — দুটি পরিচিত দরজা

Client আর backend-এর মাঝখানে প্রায়ই একটি স্তর বসে। নাম দুটি গুলিয়ে যায়, কারণ দুটিই দরজার মতো। হোটেলের সাথে মিলিয়ে দেখুন।

Sam Newman তাঁর লেখায় BFF নামটির কৃতিত্ব SoundCloud-এর প্রাক্তন প্রকৌশলী Phil Calçado-কে দেন। Next.js-এর দাপ্তরিক docs-এও Backend for Frontend নামে একটি গাইড আছে, কারণ তার route handler স্বাভাবিকভাবেই এই ভূমিকা নিতে পারে। বাজারঘরে শুরুতে gateway বা আলাদা BFF কোনোটিই লাগবে না, যদি একটি অ্যাপ আর একটি client থাকে। একটি reverse proxy (সামনে বসে অনুরোধ নিয়ে অ্যাপে পাঠানো server) থাকলেই চলে। গভীর আলোচনা, ঝুঁকি আর “smart gateway” ফাঁদের জন্য দেখুন API gateway ও proxy.

৯ · আসল framework-এ কে কোথায়, আর বাজারঘরের সিদ্ধান্ত

Framework নাম দেয় নিজের মতো করে, কিন্তু দায়িত্বের ভাগ প্রায় একই থাকে। এই টেবিলটি হাতের কাছে রাখলে নতুন framework শিখতে সুবিধা হবে।

• Express: সে নিজেকে “unopinionated” বলে। গঠন আপনার দায়িত্ব। স্বাধীনতার দাম হলো শৃঙ্খলা নিজেকে রাখতে হয়। তাই এই পর্বের স্তরগুলো সবচেয়ে বেশি লাগে এখানে।
• Django: MVT নামটিই বিভ্রান্তির উৎস। Django-র দাপ্তরিক FAQ বলছে, তাদের “view” ঠিক করে কোন data দেখানো হবে, আর template ঠিক করে কীভাবে; controller-এর কাজটি মোটামুটি framework নিজেই করে। পর্ব ৬৮-তে হাতে-কলমে।
• Laravel: web MVC-র সোজা রূপ, পর্ব ৭০-এ দেখবেন। তার docs বলে, class কোথায় রাখবেন সেই বিষয়ে প্রায় কোনো বাধা নেই, তাই অনেক দল নিজেরাই service layer যোগ করে।
• Next.js: Server Component সরাসরি database ছুঁতে পারে, এতে স্তরগুলো হারিয়ে গেছে বলে মনে হয়। আসলে তা নয়। বর্তমান docs নতুন প্রজেক্টে একটি আলাদা Data Access Layer রাখার পরামর্শ দেয়, যা শুধু server-এ চলে, অনুমতি যাচাই করে আর ন্যূনতম data ফেরত দেয়। পর্ব ৫২ আর পর্ব ৫৪ দেখবেন।

বাজারঘরের সিদ্ধান্ত

ধরা যাক দলে তিনজন, নতুন পণ্য, ক্রেতা কত আসবেন এখনো অজানা। আমাদের সিদ্ধান্ত: feature folder-সহ modular monolith, প্রতিটি feature-এর ভেতরে তিন স্তর, এক database. নিয়ম চারটি:

1. প্রতিটি feature (catalog, cart, order, payment, auth) বাইরে শুধু একটি index.js দেখায়।
2. এক feature আরেক feature-এর repository বা table সরাসরি ছোঁবে না; তার service ডাকবে।
3. Circular import থাকলে CI (কোড জমা দিলে নিজে চলা যাচাই) আটকে দেবে (পর্ব ৮১)।
4. বড় সিদ্ধান্ত ছোট করে লিখে রাখা হবে, কেন নেওয়া হলো সহ।

Modular monolith-এর সুবিধা এখানেই: সীমা আগে থেকে পরিষ্কার থাকলে পরে বের করা সস্তা হয়। ১০০ থেকে ১০ লাখ ব্যবহারকারীর পথ দেখবেন পর্ব ৮৭-তে, আর stack বাছাইয়ের ছক পর্ব ৮৫-তে।

১০ · AI-এর যুগে — architecture-এর পরামর্শ যাচাই

AI খুব দ্রুত folder বানিয়ে দিতে পারে। কিন্তু সে আপনার দলের আকার, বাজেট আর ক্রেতার সংখ্যা জানে না, যদি না আপনি বলেন। তাই AI প্রায়ই প্রথম উত্তরে “Kubernetes-এ পাঁচটি microservice” বলে ফেলে, কারণ লেখালেখিতে সেটিই বেশি চোখে পড়ে।

AI-এর দেওয়া নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• দল, ট্র্যাফিক আর বাজেটের সাথে নকশাটি মিলিয়ে দেখেছি
• প্রতিটি নতুন package আর API আমার version-এর দাপ্তরিক docs-এ পেয়েছি
• কোড চালিয়েছি এবং diff লাইন ধরে পড়েছি
• Service-এর নিয়মের জন্য অন্তত একটি test লিখেছি, ব্যর্থ পথসহ
• madge --circular চালিয়েছি, কোনো চক্র নেই
• অনুমতি যাচাই server-এ আছে, আর কোথাও secret লেখা নেই