Software architecture — layered, client-server, pipe-filter, event-driven আর ADR

১ · Software architecture কী — বাড়ির নকশা থেকে system-এর কাঠামো

মডিউল ৫ আর ৬-এ আপনি ছোট পরিসরে নকশা দেখেছেন: একটি class কতটা দায়িত্ব নেবে (পর্ব ২৭), দুটি object কীভাবে কথা বলবে (পর্ব ৩৫), dependency কোথা থেকে আসবে (পর্ব ৩৭)। এবার ক্যামেরা পিছিয়ে নিচ্ছি। মডিউল ৭ শুরু হচ্ছে পুরো system-এর কাঠামো দিয়ে — এই পর্বে software architecture, তারপর UI-র কোড সাজানো (পর্ব ৩৯), domain-কে কেন্দ্রে রাখা clean ও hexagonal architecture (পর্ব ৪০)। এরপর আবার কাছে আসব — clean code (পর্ব ৪১), code smell আর refactoring (পর্ব ৪২), technical debt আর legacy code (পর্ব ৪৩), আর code review (পর্ব ৪৪)। পুরো মডিউলের প্রশ্ন একটাই: software বছরের পর বছর বদলানো যায় কীভাবে?

তিনটি পরিচিত সংজ্ঞা

Architecture-এর কোনো একক সর্বসম্মত সংজ্ঞা নেই — আর এটা লুকানোর কিছু নয়। তিনটি বহুল উদ্ধৃত দৃষ্টিভঙ্গি পাশাপাশি রাখলে ছবি পরিষ্কার হয়:

Architecture বনাম design

একটি প্রচলিত বাক্য আছে: সব architecture-ই design, কিন্তু সব design architecture নয়। পার্থক্যটা মূলত পরিসর আর বদলের দামে। Software design-এর একটি বড় অংশ এক module বা কয়েকটি class-এর ভেতরে থাকে; architecture সেই সিদ্ধান্তগুলো, যেগুলো অনেক module, অনেক দল বা পুরো system-এর গুণকে একসাথে প্রভাবিত করে।

সীমারেখাটা ঝাপসা, আর সেটাই স্বাভাবিক। ছোট app-এ “কোন ORM ব্যবহার করব” একটি সাধারণ design প্রশ্ন; লাখো ব্যবহারকারীর payment system-এ একই প্রশ্ন architecture হয়ে ওঠে, কারণ তার ওপর performance, নিরাপত্তা আর দশটি দলের কোড নির্ভর করে। এই পর্বের পুরো উদাহরণ একটি কাল্পনিক system: “টিকিটঘর” — আন্তঃজেলা বাসের টিকিট কেনার একটি কাল্পনিক app, যার সবচেয়ে কঠিন সময় ঈদের আগের দুই সপ্তাহ, যখন ভিড় স্বাভাবিকের বহু গুণ।

২ · Architecture-কে কী চালায় — driver আর quality attribute scenario

একই functional requirement-এর জন্য দশটি ভিন্ন architecture বানানো যায়। “যাত্রী টিকিট খুঁজবেন, আসন বাছবেন, পেমেন্ট করবেন, SMS পাবেন” — এটুকু একটি PHP script-এও হয়, পঞ্চাশটি microservice-এও হয়। তাহলে কোনটা বেছে নেবেন, তা ঠিক করে কে? উত্তর: architectural driver — যে requirement আর শর্তগুলো কাঠামোর আকার ঠিক করে দেয়। তিন ধরনের driver আছে:

Functional আর non-functional requirement-এর পার্থক্য, আর NFR-কে সংখ্যায় বাঁধার কৌশল (fit criterion, Planguage) পর্ব ২১-এ এসেছে। Architecture-এর কাজে সেই সংখ্যাগুলো আরও একটি কাঠামোয় লেখা হয়: quality attribute scenario. SEI-র লেখকেরা (Bass, Clements ও Kazman) এর ছয়টি অংশ ব্যবহার করেন। পর্ব ৩-এ একটি ফলাফল পোর্টালের performance scenario লিখেছিলেন; এখানে নিচ্ছি architecture-এর জন্য সবচেয়ে গুরুত্বপূর্ণ কিন্তু সবচেয়ে অবহেলিত গুণটি — modifiability, অর্থাৎ বদলানোর সহজতা।

টিকিটঘর-এর জন্য আরও দুটি scenario সংক্ষেপে — পুরো কার্ড না লিখে এক লাইনে, যেমনটি অনেক দল তাদের তালিকায় রাখে:

৩ · Layered architecture — strict, relaxed আর sinkhole

প্রথমে চারটি প্রধান style একসাথে এক নজরে দেখে নিন; তারপর একে একে ভেতরে ঢুকব।

Layered architecture সবচেয়ে পরিচিত, আর অনেক দলের “ডিফল্ট” পছন্দ। কোড ওপর-নিচে ভাগ হয়: ওপরে presentation (web page, mobile screen, API controller), তার নিচে application (একটি use case-এর ধাপ সমন্বয়: “একটি বুকিং” মানে আসন যাচাই, ভাড়া হিসাব, পেমেন্ট শুরু), তার নিচে domain (ব্যবসার নিয়ম: একই আসন দুজনকে নয়), আর একদম নিচে data (database-এ পড়া-লেখা)। মূল নিয়ম একটাই: নির্ভরতা শুধু নিচের দিকে। Domain কখনো জানবে না কোন screen তাকে ডাকছে। এটি পর্ব ২৬-এর separation of concerns-এর বড় আকার। আরেকটি পরিচিত উদাহরণ network-এর protocol stack — TCP/IP-এ application, transport, network, link — যা Computer Networks কোর্সে বিস্তারিত।

Strict বনাম relaxed

Strict (closed) layering-এ একটি স্তর শুধু ঠিক নিচের স্তরটিকে ডাকতে পারে — presentation সরাসরি data-তে যেতে পারে না, application আর domain পেরিয়েই যেতে হবে। Relaxed (open) layering-এ নিচের যেকোনো স্তর ডাকা যায়। Strict-এর লাভ: data স্তর বদলালে শুধু domain-কে মানিয়ে নিতে হয়, বাকিরা নিরাপদ। দাম: অনেক “শুধু পার করে দেওয়া” কোড। বাস্তবে অনেক দল মিশ্র নিয়ম রাখে — কিছু স্তর (যেমন একটি shared utility স্তর) “open” ঘোষণা করা, বাকিগুলো “closed”. কোন নিয়ম, তা লিখে রাখাই আসল কথা — নইলে প্রত্যেকে নিজের মতো ধরে নেন। নিয়ম লেখা থাকলে যন্ত্র দিয়ে যাচাইও করা যায়:

// Layer-violation checker: strict vs relaxed layering (fictional bus-ticket app).
const layer = {                       // 4 = top, 1 = bottom
  BookingPage: 4, AdminPage: 4,       // presentation
  BookingService: 3, FareService: 3,  // application
  Seat: 2, Fare: 2,                   // domain
  TicketRepo: 1, Db: 1                // data
};
const imports = [                     // [from, to]
  ["BookingPage", "BookingService"], ["BookingService", "FareService"],
  ["BookingService", "Seat"],        ["BookingService", "TicketRepo"],
  ["FareService", "Fare"],           ["Fare", "FareService"],
  ["AdminPage", "TicketRepo"],       ["Seat", "TicketRepo"],
  ["TicketRepo", "Db"]
];
function check(mode) {
  const found = [];
  for (const [from, to] of imports) {
    const gap = layer[from] - layer[to];        // > 0 means "goes down"
    const edge = `${from}(${layer[from]}) -> ${to}(${layer[to]})`;
    if (gap < 0) found.push("UP   " + edge);    // never allowed
    else if (mode === "strict" && gap > 1) found.push("SKIP " + edge);
  }
  return found;
}
for (const mode of ["strict", "relaxed"]) {
  const v = check(mode);
  console.log(`${mode}: ${v.length} violation(s) in ${imports.length} imports`);
  v.forEach(line => console.log("  " + line));
}

strict: 3 violation(s) in 9 imports
  SKIP BookingService(3) -> TicketRepo(1)
  UP   Fare(2) -> FareService(3)
  SKIP AdminPage(4) -> TicketRepo(1)
relaxed: 1 violation(s) in 9 imports
  UP   Fare(2) -> FareService(3)

Sinkhole anti-pattern আর layered-এর দাম

ধরুন যাত্রী শুধু “আমার পুরোনো টিকিটগুলো দেখান” চাইলেন। Controller ডাকল TicketService.list(), যে ডাকল TicketDomain.list(), যে ডাকল TicketRepo.list() — মাঝের দুটি স্তর কিছুই করল না, শুধু পার করে দিল। Mark Richards এমন অবস্থার নাম দিয়েছেন architecture sinkhole anti-pattern. কিছু অনুরোধ এমন হবেই; Richards মোটা দাগে একটি ৮০-২০ নিয়মের কথা বলেন — প্রায় ২০ শতাংশ অনুরোধ “শুধু পার” হলে স্বাভাবিক, কিন্তু অনুপাত উল্টে গেলে স্তরগুলো খরচ ছাড়া কিছু দিচ্ছে না। তখন কিছু স্তর open করা বা অন্য style ভাবা যায়।

৪ · Client-server, pipe-and-filter আর microkernel

Client-server

Client-server-এ এক পক্ষ অনুরোধ পাঠায় (client), আরেক পক্ষ সেবা ও ডেটার মালিক হয়ে উত্তর দেয় (server). টিকিটঘর-এর mobile app আর web page হলো client; API server আর database হলো server-এর দিক। রেলস্টেশনের টিকিট কাউন্টারের মতো — যাত্রী অনেক, কাউন্টারের ওপারে খাতা একটাই, আর খাতায় শুধু কাউন্টারের লোক লেখেন। মূল সিদ্ধান্তগুলো:

• Client কতটা “বুদ্ধিমান”: thin client শুধু দেখায়; rich client নিজেও হিসাব করে (যেমন offline-এ আসনের তালিকা রাখা)। নিয়ম client-এ থাকলে প্রতিটি app version আলাদা নিয়ম চালাতে পারে — পুরোনো app ফোনে বছরখানেক থেকে যায়। তাই বিশ্বাসযোগ্য নিয়ম, যেমন ভাড়া আর আসন বরাদ্দ, server-এ; client-এর যাচাই শুধু সুবিধার জন্য (পর্ব ৩১-এর trust boundary).
• Layer বনাম tier: layer কোডের ভাগ, tier চালানোর জায়গার ভাগ। Browser, application server আর database server — তিনটি tier; একে n-tier বা three-tier বলা হয়। একটি tier-এর ভেতরে কয়েকটি layer থাকতে পারে।
• বিকল্প: peer-to-peer, যেখানে প্রতিটি অংশ client-ও, server-ও (যেমন BitTorrent) — কেন্দ্রীয় খাতা নেই, তাই নিয়ন্ত্রণ আর সামঞ্জস্য কঠিন।

HTTP, TLS আর socket-এর স্তরে client-server কীভাবে কথা বলে, তা Computer Networks কোর্সে; API-র নকশা System Design কোর্সের REST পর্বে।

Pipe-and-filter

Pipe-and-filter-এ কাজটি কয়েকটি স্বাধীন ধাপে ভাগ: প্রতিটি filter ইনপুট নেয়, রূপান্তর করে, আউটপুট দেয়; pipe এক filter-এর আউটপুটকে পরের ইনপুটে পৌঁছায়। Filter জানে না তার আগে বা পরে কে — শুধু ডেটার আকার মানে। গার্মেন্টস কারখানার সেলাই লাইনের মতো: কাটিং, সেলাই, বোতাম, ইস্ত্রি — প্রতিটি টেবিল নিজের কাজ জানে, আর একটি টেবিল বদলালে বাকিদের কিছু শিখতে হয় না। Unix-এর | এর বিখ্যাত রূপ; compiler-এর ধাপ, ছবি প্রক্রিয়াকরণ আর ডেটা প্রক্রিয়াকরণের ETL-ও তাই। পর্ব ৩৬-এর chain of responsibility আর middleware এর ঘনিষ্ঠ আত্মীয়।

নিচের কোডে টিকিটঘর-এর যাত্রী-মতামত থেকে সবচেয়ে বেশি আসা শব্দ বের করা হচ্ছে। Python-এর generator দিয়ে প্রতিটি filter লেখা (generator-এর বিস্তারিত Python কোর্সে), তাই ডেটা এক লাইন করে বয়ে যায়, পুরোটা memory-তে জমে না:

import re
from collections import Counter

FEEDBACK = """Bus late again! The AC bus was LATE.
Seat 7 broken; bus staff polite, bus late.
"""

def read(text):                      # source: one line at a time
    for n, line in enumerate(text.splitlines(), 1):
        print(f"  [read line {n}]")
        yield line

def clean(lines):                    # filter: lower case, letters only
    for line in lines:
        yield re.sub(r"[^a-z ]", " ", line.lower())

def tokenize(lines):                 # filter: line -> words
    for line in lines:
        yield from line.split()

def drop_stopwords(words, stop=frozenset({"the", "was", "again", "ac"})):
    for w in words:                  # an extra filter with the same shape
        if w not in stop:
            yield w

def run(source, *filters):           # the pipes: connect filters in order
    for f in filters:
        source = f(source)
    return source

words = run(read(FEEDBACK), clean, tokenize)
print("first word:", next(words))    # only line 1 has been read so far
print("count A:", Counter(words).most_common(3))
words = run(read(FEEDBACK), clean, tokenize, drop_stopwords)
print("count B:", Counter(words).most_common(3))

  [read line 1]
first word: bus
  [read line 2]
count A: [('late', 3), ('bus', 3), ('again', 1)]
  [read line 1]
  [read line 2]
count B: [('bus', 4), ('late', 3), ('seat', 1)]

Microkernel বা plugin architecture

Microkernel architecture-এ একটি ছোট core থাকে, যা একটি প্রকাশিত চুক্তি (interface) আর নিবন্ধনের ব্যবস্থা (registry) দেয়; নতুন ক্ষমতা আসে plugin হিসেবে। পর্ব ২৭-এ open-closed principle-এর registry আর plugin architecture এই ধরনের class-স্তরের রূপ ছিল। বড় পরিসরে উদাহরণ: অনেক code editor ও IDE-র extension, browser-এর extension, আর টিকিটঘর-এ প্রতিটি payment পদ্ধতিকে plugin বানানো — তাহলে অংশ ২-এর modifiability scenario (“payment-এর বাইরে ০টি file”) প্রায় আপনাআপনি পাস করে।

৫ · Event-driven architecture — broker বনাম mediator

Event-driven architecture-এ অংশগুলো একে অপরকে সরাসরি “এই কাজটি এখনই করতে হবে” বলে না; বরং ঘোষণা করে “এটা ঘটেছে” — BookingPaid, SeatReleased. যারা আগ্রহী, তারা শোনে আর নিজের কাজ করে। মাঝখানে থাকে একটি event broker (message broker বা queue). পর্ব ৩৫-এর observer pattern এক process-এর ভেতরে এই কাজটি করত; এখানে একই ধারণা process আর service-এর সীমা পেরিয়ে, সাধারণত asynchronous ভাবে (publish-subscribe). লাভ: প্রকাশক গ্রাহকদের চেনে না, তাই নতুন গ্রাহক (যেমন loyalty point) যোগ করতে booking-এর কোড বদলায় না; আর SMS ধীর হলেও booking অপেক্ষা করে না।

Mark Richards ও Neal Ford-এর Fundamentals of Software Architecture (২০২০) বইয়ে এই style-এর দুটি রূপ (topology) আলাদা করা হয়। নিচের stepper-এ একই কাজ — টিকিট বুকিং — দুই রূপে দেখুন, বিশেষ করে ভুল হলে কী হয়:

সংক্ষেপে: সহজ, স্বাধীন প্রতিক্রিয়ার জন্য (SMS, log, point) broker; ক্রম মেনে চলা, ব্যর্থ হলে ফেরাতে হয় এমন ব্যবসায়িক প্রবাহের জন্য (বুকিং-পেমেন্ট) mediator. বাস্তবে একই system-এ দুটোই থাকে। Event-driven-এর সাধারণ দাম মনে রাখুন: “কাজ হয়ে গেছে” কথাটি দেরিতে সত্য হয় (eventual consistency), একই event দুবার আসতে পারে বলে গ্রাহককে idempotent হতে হয়, আর ক্রম নিশ্চিত নয়। Fan-out, delivery guarantee, choreography বনাম orchestration আর saga-র distributed গভীরতা System Design কোর্সের Pub/sub আর event-driven architecture পর্বে — এখানে আর পুনরাবৃত্তি করছি না।

Space-based — চরম ভিড়ের জন্য, সংক্ষেপে

ঈদের আগে টিকিট ছাড়ার মুহূর্তে হঠাৎ লাখো মানুষ একসাথে ঢুকলে একটি database-ই বোতলের গলা হয়ে দাঁড়ায়। Space-based architecture (নামটি “tuple space” ধারণা থেকে; Richards ও Ford-এর বইয়ে বিস্তারিত) এর উত্তর: অনেকগুলো processing unit, প্রতিটির memory-তে ডেটার কপি (in-memory data grid), কপিগুলোর মধ্যে সমন্বয়, আর database-এ লেখা পরে asynchronous ভাবে। ভিড় বাড়লে unit বাড়ে। দাম বড়: জটিলতা, খরচ, কপির মধ্যে অসামঞ্জস্যের ঝুঁকি, test করা কঠিন। তাই এটি ব্যতিক্রমী ভিড়ের জন্য — সাধারণ business app-এর ডিফল্ট নয়।

৬ · Monolith, modular monolith আর microservices — driver দিয়ে বাছাই

Style-এর আরেকটি অক্ষ হলো deploy-এর একক। Monolith মানে পুরো app একসাথে build ও deploy হয় — এটি নিজে খারাপ কিছু নয়। খারাপ হলো ভেতরে সীমাহীন জট (“big ball of mud”). Modular monolith-এ deploy একটিই, কিন্তু ভেতরে module-এর কঠোর সীমা: প্রতিটি module নিজের ডেটার মালিক, অন্যরা শুধু তার public interface ডাকে। Microservice-এ প্রতিটি ভাগ আলাদা process, আলাদা deploy, network-এ কথা বলে।

সবচেয়ে বিপজ্জনক অবস্থা হলো distributed monolith: দেখতে আলাদা service, কিন্তু সব একসাথে বদলায় আর deploy হয় — microservice-এর খরচ, monolith-এর জট (পর্ব ২৫-এর অংশ ৮)। Service-এর সীমা, discovery, service mesh আর distributed খরচের বিস্তারিত System Design কোর্সের Monolith বনাম microservices পর্বে।

তাহলে টিকিটঘর কোনটি নেবে? নিচের stepper-এ driver থেকে সিদ্ধান্ত পর্যন্ত একটি পূর্ণ যুক্তির পথ:

// Weighted trade-off matrix: 3 candidate styles for a fictional bus-ticket app.
const attrs = [                      // [quality attribute, weight 1..5]
  ["peak availability", 5], ["modifiability", 4],
  ["operational simplicity", 4], ["independent scaling", 2]
];
const styles = {                     // score 1..5 per attribute, same order
  "layered monolith":  [2, 2, 5, 1],
  "modular monolith":  [3, 4, 4, 2],
  "microservices":     [4, 4, 1, 5]
};
function rank(weights) {
  return Object.entries(styles)
    .map(([name, s]) => [name, s.reduce((t, x, i) => t + x * weights[i], 0)])
    .sort((a, b) => b[1] - a[1]);
}
const base = attrs.map(a => a[1]);
const max = base.reduce((t, w) => t + 5 * w, 0);
rank(base).forEach(([n, t], i) => console.log(`${i + 1}. ${n.padEnd(17)} ${t} / ${max}`));
console.log("sensitivity (change one weight, others fixed):");
attrs.forEach(([name], i) => {
  const winners = [];
  for (let w = 1; w <= 5; w++) {
    const ws = base.slice(); ws[i] = w;
    const r = rank(ws);
    winners.push(w + ":" + (r[0][1] === r[1][1] ? "tie" : r[0][0].split(" ")[0]));
  }
  console.log(`  ${name.padEnd(23)} ${winners.join("  ")}`);
});

1. modular monolith  51 / 75
2. microservices     50 / 75
3. layered monolith  40 / 75
sensitivity (change one weight, others fixed):
  peak availability       1:modular  2:modular  3:modular  4:modular  5:modular
  modifiability           1:modular  2:modular  3:modular  4:modular  5:modular
  operational simplicity  1:microservices  2:microservices  3:microservices  4:modular  5:modular
  independent scaling     1:modular  2:modular  3:microservices  4:microservices  5:microservices

৭ · Architecture-এর ছবি — 4+1 view আর C4 model

একটি বাড়ির একটি নকশায় সব ধরে না: স্থপতির floor plan, বৈদ্যুতিক লাইনের নকশা, পানির পাইপের নকশা, আর বাইরে থেকে দেখতে কেমন — চারটি আলাদা কাগজ, চারজন আলাদা পাঠক। Software-এও একই কথা। প্রতিটি দৃষ্টিকোণ থেকে আঁকা বর্ণনাকে বলে architectural view.

Kruchten-এর 4+1 view model (১৯৯৫)

Philippe Kruchten ১৯৯৫ সালে IEEE Software-এ “The 4+1 View Model of Architecture” প্রবন্ধে চারটি view আর সেগুলোকে বাঁধা পঞ্চম একটি view প্রস্তাব করেন — 4+1 view model. পরে এটি Rational Unified Process-এর অংশ হয়ে বহুল পরিচিত হয়।

C4 model — মানচিত্রের মতো zoom

Simon Brown-এর প্রস্তাবিত C4 model ২০১০-এর দশকে বিশেষ জনপ্রিয় হয়েছে; এর বর্ণনা তাঁর লেখা ও c4model.com-এ। চিন্তাটি Google Maps-এর মতো — দেশ, শহর, রাস্তা, বাড়ি:

1. Context: পুরো system একটি বাক্স; চারপাশে মানুষ (ব্যবহারকারী) আর বাইরের system. প্রযুক্তির নাম প্রায় থাকেই না — ব্যবসার লোকও পড়তে পারেন।
2. Container: System-এর ভেতরের আলাদাভাবে চালানো বা deploy করা যায় এমন একক — web app, mobile app, API, database, queue. (এখানে “container” মানে Docker container নয়, যদিও প্রায়ই মিলে যায়।)
3. Component: একটি container-এর ভেতরের বড় অংশগুলো — যেমন API-র ভেতরে booking, payment, fare module.
4. Code: class diagram-এর স্তর; প্রায়ই আঁকা হয় না, বা tool দিয়ে কোড থেকে তৈরি হয়।

৮ · ADR — সিদ্ধান্ত লিখে রাখা, Git-এ রাখা

দুই বছর পর একজন নতুন developer জিজ্ঞেস করবেন: “এত বড় app, অথচ microservices নয় কেন?” যিনি সিদ্ধান্ত নিয়েছিলেন, তিনি হয়তো চলে গেছেন। Wiki-র ৮০ পাতার architecture document কেউ হালনাগাদ করেনি। এই সমস্যার হালকা সমাধান Architecture Decision Record (ADR) — প্রতিটি গুরুত্বপূর্ণ সিদ্ধান্তের জন্য এক-দুই পাতার একটি ফাইল। Michael Nygard ২০১১ সালের নভেম্বরে “Documenting Architecture Decisions” নামের একটি blog লেখায় যে ছাঁচ দেন, তাতে পাঁচটি অংশ: title, status, context, decision, consequences. পরে MADR-এর মতো আরও বিস্তারিত ছাঁচ এসেছে (বিকল্পগুলোর তালিকাসহ), কিন্তু মূল চিন্তা একই।

# 1. Use a modular monolith

Date: 2026-01-15

## Status

Accepted

## Context

Ticketghor (fictional) sells inter-district bus tickets. Five developers,
one operations person, launch before Eid in six months. Traffic is about
20 times normal in the two weeks before Eid. Booking, payment, fares and
notifications change at different speeds.

## Decision

We will build one deployable application split into modules
(booking, payment, fares, notify). A module may call another only through
its public interface. No module reads another module's tables.
An automated architecture test in CI enforces these rules.

## Consequences

- One deployment, one database, simple operations for a small team.
- Peak load is handled by running more copies of the whole application;
  we cannot scale one module alone.
- If a module later needs independent scaling or release, its clean
  boundary makes extracting it as a service possible (new ADR needed).

$ git add docs/adr/0001-use-a-modular-monolith.md
$ git commit -m "docs(adr): 0001 use a modular monolith"
…
# তিন মাস পরে: নতুন ADR, পুরোনোটির শুধু status বদল
-Accepted
+Accepted. Amended by ADR 0002.

পুরো ADR ফাইলটি একসাথে (ইংরেজিতে লেখা, কারণ অনেক দলে কোডের দলিল ইংরেজিতে থাকে; বাংলায় লিখলেও কাঠামো একই):

# 1. Use a modular monolith

Date: 2026-01-15

## Status

Accepted

## Context

Ticketghor (fictional) sells inter-district bus tickets. Five developers,
one operations person, launch before Eid in six months. Traffic is about
20 times normal in the two weeks before Eid. Booking, payment, fares and
notifications change at different speeds.

## Decision

We will build one deployable application split into modules
(booking, payment, fares, notify). A module may call another only through
its public interface. No module reads another module's tables.
An automated architecture test in CI enforces these rules.

## Consequences

- One deployment, one database, simple operations for a small team.
- Peak load is handled by running more copies of the whole application;
  we cannot scale one module alone.
- If a module later needs independent scaling or release, its clean
  boundary makes extracting it as a service possible (new ADR needed).

এবার একটি scratch repository-তে আসল Git-এ (Git ২.৫৩-এ, লেখক Rahim, নির্দিষ্ট তারিখে) দুটি ADR যোগ করা হলো। প্রথম commit-টি project শুরুর (README.md), সেটি বাদ দিয়ে দেখানো হচ্ছে। Repository শুরু আর প্রথম commit-এর পূর্ণ ধাপ পর্ব ৮-এ:

$ git add docs/adr/0001-use-a-modular-monolith.md
$ git commit -m "docs(adr): 0001 use a modular monolith"
[main c6435dc] docs(adr): 0001 use a modular monolith
 1 file changed, 29 insertions(+)
 create mode 100644 docs/adr/0001-use-a-modular-monolith.md
# (three months later: 0002 written, 0001's status line edited)
$ git add docs/adr
$ git commit -m "docs(adr): 0002 extract notify as a service"
[main e9ed096] docs(adr): 0002 extract notify as a service
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 docs/adr/0002-extract-notify-as-a-service.md
$ git log --oneline -- docs/adr
e9ed096 docs(adr): 0002 extract notify as a service
c6435dc docs(adr): 0001 use a modular monolith
$ git diff HEAD~1 -- docs/adr/0001-use-a-modular-monolith.md
…
@@ -4,7 +4,7 @@ Date: 2026-01-15

 ## Status

-Accepted
+Accepted. Amended by ADR 0002.

 ## Context
 

এখানে Git ঠিক সেই কাজটি করছে, যা wiki পারে না: git log -- docs/adr সিদ্ধান্তের পূর্ণ ইতিহাস দেখায়, কে কখন বদলেছে (পর্ব ৯-এর log আর diff). ADR 0001-এর diff-এ মাত্র একটি লাইন বদলেছে — status; প্রেক্ষাপট আর যুক্তি অক্ষত। আর সিদ্ধান্তটি যে commit-এ এসেছে, সেই একই commit বা PR-এ কোডের বদলও থাকতে পারে — তখন review-এর সময় reviewer কারণ আর কোড পাশাপাশি দেখেন।

৯ · Architecture যাচাই আর রক্ষা — ATAM, fitness function আর Conway's law

ATAM — সংক্ষেপে

বড় সিদ্ধান্তের আগে architecture-কে আনুষ্ঠানিকভাবে যাচাই করার একটি পরিচিত পদ্ধতি SEI-র ATAM (Architecture Tradeoff Analysis Method), যা ২০০০ সালের দিকে Kazman, Klein ও Clements-এর কাজে প্রকাশিত। মোটা দাগে: ব্যবসার লক্ষ্য আর architecture উপস্থাপন, quality attribute থেকে শুরু করে পাতায় অগ্রাধিকারসহ scenario — একটি utility tree — বানানো, তারপর গুরুত্বপূর্ণ scenario ধরে architecture-এর পদ্ধতিগুলো বিশ্লেষণ। ফলাফল চার ধরনের: ঝুঁকি (risk), ঝুঁকি-নয় (non-risk), sensitivity point আর trade-off point. অংশ ৬-এর কোডে “সহজ চালানো”-র ওজন ছিল একটি sensitivity point; আর mediator — যে প্রবাহ পরিষ্কার করে কিন্তু coupling বাড়ায় — একটি trade-off point. পূর্ণ ATAM কয়েক দিনের, অনেক stakeholder-এর অনুষ্ঠান; ছোট দলে এর হালকা রূপ — এক বিকেলে scenario ধরে প্রস্তাব যাচাই — প্রায়ই যথেষ্ট।

Fitness function — architecture-কে test-এ বাঁধা

ADR-এ “কোনো module অন্যের table পড়বে না” লেখা হলো। ছয় মাস পর, এক ব্যস্ত রাতে, কেউ admin page থেকে সরাসরি database ডেকে ফেললেন — “শুধু এবারই”। এভাবে ছোট ছোট শর্টকাটে কোড পরিকল্পনা থেকে সরে যাওয়াকে বলে architecture erosion; technical debt-এর একটি বড় উৎস (পর্ব ৪৩)। প্রতিরোধ: নিয়মটিকে যন্ত্রে যাচাইযোগ্য করা। Neal Ford, Rebecca Parsons ও Patrick Kua-র Building Evolutionary Architectures (২০১৭; পরের সংস্করণে Pramod Sadalage-ও যুক্ত) বইয়ে এর নাম architectural fitness function — architecture-এর কোনো গুণের বস্তুনিষ্ঠ, সম্ভব হলে স্বয়ংক্রিয়, মাপ। উদাহরণ: নিষিদ্ধ import খোঁজার test, load test-এ p95 latency-র সীমা, cyclomatic complexity-র সীমা (পর্ব ৫০)। নিচে প্রথমটি — Python-এর নিজের ast parser দিয়ে import পড়া, আর unittest-এ নিয়ম:

import ast, unittest

SOURCES = {                          # fictional bus-ticket app: file -> source
    "ui/booking_page.py": "from app.booking import book\n",
    "ui/admin_page.py":   "import db\nfrom app.reports import daily\n",
    "app/booking.py":     "from domain.seat import Seat\nfrom data.tickets import save\n",
    "app/reports.py":     "from data.tickets import all_tickets\n",
    "domain/seat.py":     "from dataclasses import dataclass\n",
    "data/tickets.py":    "import db\n",
}

def top_imports(src):                # {"db", "app", ...} read with Python's own parser
    names = set()
    for node in ast.walk(ast.parse(src)):
        if isinstance(node, ast.Import):
            names |= {a.name.split(".")[0] for a in node.names}
        elif isinstance(node, ast.ImportFrom) and node.module:
            names.add(node.module.split(".")[0])
    return names

class ArchitectureFitness(unittest.TestCase):
    def test_only_data_layer_imports_db(self):
        bad = [f for f, s in SOURCES.items()
               if "db" in top_imports(s) and not f.startswith("data/")]
        if bad: self.fail("db imported outside data/: " + ", ".join(bad))
    def test_domain_imports_no_outer_layer(self):
        bad = [f for f, s in SOURCES.items() if f.startswith("domain/")
               and top_imports(s) & {"ui", "app", "data", "db"}]
        self.assertEqual(bad, [])

result = unittest.TestResult()
unittest.defaultTestLoader.loadTestsFromTestCase(ArchitectureFitness).run(result)
for test, tb in result.failures:
    print("FAIL", test._testMethodName, "->", tb.strip().splitlines()[-1])
print(f"ran {result.testsRun}, failed {len(result.failures)}")

FAIL test_only_data_layer_imports_db -> AssertionError: db imported outside data/: ui/admin_page.py
ran 2, failed 1

Conway's law — দলের কাঠামোও architecture

Melvin Conway-এর ১৯৬৮ সালের পর্যবেক্ষণ — Conway's law — পর্ব ১ আর পর্ব ২৫-এ এসেছে: system-এর কাঠামো তার নির্মাতা প্রতিষ্ঠানের যোগাযোগের কাঠামোর প্রতিচ্ছবি হয়। Architecture-এর দিক থেকে এর অর্থ: দশটি microservice-এর পরিকল্পনা পাঁচজনের একটি দলে টেকসই হওয়া কঠিন, কারণ সবাই সব service-এ হাত দেবেন আর সীমাগুলো ঝাপসা হবে। উল্টো দিক থেকে ব্যবহার — আগে কাঙ্ক্ষিত কাঠামো ঠিক করে সেই অনুযায়ী দল সাজানো — কে বলে inverse Conway maneuver. তাই টিকিটঘর-এর ADR-এর context-এ দলের আকার লেখা ছিল: সেটি কোনো পার্শ্বতথ্য নয়, একটি driver.

১০ · AI-এর যুগে software architecture

AI-কে “আমার app-এর architecture বলে দাও” লিখে চাইলে কয়েক সেকেন্ডে একটি চকচকে উত্তর আসে — প্রায়ই দশটি service, একটি message broker, Kubernetes আর একটি সুন্দর ছবি। সমস্যা হলো, AI আপনার দলের আকার, বাজেট, ঈদের ভিড় বা একজন ops-এর কথা জানে না, যদি না আপনি বলেন; আর বললেও তার ঝোঁক থাকে জনপ্রিয় উত্তরের দিকে। Architecture-এ AI খুব ভালো প্রতিপক্ষ — বিকল্প খোঁজা, আপনার ADR-এর দুর্বলতা ধরা, scenario-র খসড়া — কিন্তু সিদ্ধান্তদাতা নয়।

AI-এর architecture প্রস্তাব হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রস্তাবটি আমার লেখা driver আর constraint-এর কথা উল্লেখ করেছে — সাধারণ “best practice” নয়
• অন্তত দুটি quality attribute scenario দিয়ে প্রস্তাবটি নিজে যাচাই করেছি
• ADR-এর consequences-এ দাম লেখা আছে, আর কখন আবার ভাবতে হবে তাও
• ছবির প্রতিটি তীর আর বাক্স কোডের আসল অংশের সাথে মিলিয়েছি
• উদ্ধৃত বই, মানদণ্ড ও tool মূল উৎসে খুঁজে দেখেছি; Git command throwaway clone-এ চালিয়ে দেখেছি
• মূল নিয়মগুলো (যেমন স্তরের import) fitness function হিসেবে test-এ বেঁধেছি