Clean আর hexagonal architecture — port, adapter আর domain-driven design-এর ধারণা

১ · সমস্যা — database-কে কেন্দ্র করে সাজানো স্তর

পর্ব ৩৮-এ layered architecture দেখেছেন: ওপরে presentation, মাঝে business logic, নিচে data access আর database. প্রতিটি স্তর ঠিক নিচের স্তরকে ডাকে। নকশাটি সহজ, পরিচিত, আর অনেক app-এর জন্য যথেষ্ট। কিন্তু এর ভেতরে একটি লুকানো সিদ্ধান্ত আছে: নির্ভরতার তীর নিচের দিকে, অর্থাৎ business-এর নিয়ম database-এর দিকে তাকিয়ে আছে।

একটি কাল্পনিক অনলাইন মুদি-বাজার app ধরুন। নিয়ম: “ক্রেতার wallet-এ যথেষ্ট টাকা থাকলে order PAID, না থাকলে REJECTED; আর একটি order-এর মোট দাম ক্রেতার credit limit ছাড়াবে না।” Layered নকশায় এই নিয়মের class সাধারণত এরকম দেখায়: ভেতরে ORM-এর model import করা, সরাসরি SQL session খোলা, আর web framework-এর request object হাতে নেওয়া। কয়েক বছর পর দেখা যায় তিনটি সমস্যা:

1. নিয়মের test-এ database লাগে। “wallet-এ ৫০০ টাকা, order ৩০০ — PAID হবে” — এই এক লাইনের নিয়ম যাচাই করতেও test database চালু করতে হয়, table বানাতে হয়। Test ধীর হয়, তাই কম চালানো হয়।
2. Framework-এর বদল নিয়ম ভাঙে। ORM-এর নতুন version-এ একটি method-এর নাম বদলালে order-এর নিয়মের file-ও বদলাতে হয়, যদিও ব্যবসার নিয়মে কিছুই বদলায়নি।
3. নকশা শুরু হয় table থেকে। দল প্রথমে ভাবে “কোন কোন column?”, তারপর সেই column-এর চারপাশে কোড। ব্যবসার ভাষা (order, credit limit, wallet) হারিয়ে যায় tbl_ord_mst-এর মতো নামে।

এই চিন্তার ভিত্তি আপনি আগেই দেখেছেন। পর্ব ২৮-এর dependency inversion principle বলেছিল, উচ্চ-স্তরের নীতি নিম্ন-স্তরের খুঁটিনাটির ওপর নির্ভর করবে না; দুটিই abstraction-এর ওপর নির্ভর করবে। সেখানে কাজটি হয়েছিল একটি class-এর মাপে। এই পর্বে একই নীতি পুরো application-এর মাপে প্রয়োগ হবে, আর তার তিনটি জনপ্রিয় রূপ দেখবেন — hexagonal, onion আর Clean Architecture. শেষে আসবে domain-driven design-এর ধারণা, যা বলে কেন্দ্রের ভেতরটা কীভাবে সাজাবেন।

২ · Hexagonal architecture — port আর adapter

এই ধারণার সবচেয়ে পরিচিত নাম hexagonal architecture. Alistair Cockburn এটি বর্ণনা করেন; তাঁর প্রবন্ধটি সাধারণত ২০০৫ সালের বলে উল্লেখ করা হয়, যদিও ধারণাটি নিয়ে তিনি তার আগেও লিখছিলেন। পরে তিনি নিজেই আরও বর্ণনামূলক নাম দেন: Ports and Adapters. তাঁর লক্ষ্য ছিল এমন application, যাকে মানুষ, অন্য program, automated test বা batch script — সবাই সমানভাবে চালাতে পারে, আর যাকে আসল database বা যন্ত্র ছাড়াই তৈরি ও test করা যায়।

ছয় কোণের আকারটির কোনো গাণিতিক মানে নেই। Cockburn ছবিতে জায়গা চেয়েছিলেন, যেখানে চারপাশে একাধিক port আঁকা যায়, আর “ওপর-নিচ” (layer) ভাবনার বদলে “ভেতর-বাইরে” ভাবনা আসে। তিনটি অংশ:

• Application core (ভেতর): business-এর নিয়ম আর use case. এখানে কোনো HTTP, SQL বা framework-এর import নেই।
• Port (সীমানার দরজা): core-এর নিজের ভাষায় লেখা একটি interface — “আমি এই কাজটি করতে পারি” বা “আমার এই কাজটি কাউকে করে দিতে হবে।” Port-এর মালিক core.
• Adapter (বাইরে): বাইরের একটি নির্দিষ্ট প্রযুক্তির সাথে port-এর অনুবাদ। এটি পর্ব ৩৪-এর adapter pattern-এর বড় রূপ — একটি interface-কে আরেকটির মাপে বসানো।

Driving আর driven — দুই দিকের port

“Primary” আর “secondary” শব্দ দুটি এসেছে use case লেখার জগৎ থেকে — পর্ব ২২-এ primary actor (যিনি লক্ষ্য নিয়ে system-কে চালান) আর supporting actor (যার সাহায্য system নেয়) দেখেছেন। Cockburn নিজেও use case নিয়ে বিখ্যাত বইয়ের লেখক, তাই মিলটি কাকতালীয় নয়।

প্রতিসাম্য আর test adapter

Cockburn-এর একটি সূক্ষ্ম কথা হলো প্রতিসাম্য (symmetry): layered নকশায় UI “ওপরে” আর database “নিচে” — দুটি সম্পূর্ণ আলাদা জিনিস। Hexagonal নকশায় দুটিই সমান মর্যাদার “বাইরের জগৎ”; শুধু দিক আলাদা — একটি core-কে চালায়, আরেকটিকে core চালায়। এর সবচেয়ে বড় লাভ test-এ। Driving দিকে browser-এর বদলে একটি test script সরাসরি use case ডাকে; driven দিকে আসল database-এর বদলে একটি memory-র dictionary বসে। মাঝের core-এর এক লাইনও বদলায় না।

নিচের stepper-এ একটি order দেওয়ার অনুরোধ বাইরে থেকে ভেতরে ঢুকে আবার বেরিয়ে যাচ্ছে। প্রতিটি ধাপে দেখুন data কোন রূপে আছে, আর কে কাকে চেনে।

এবার আসল কোডে। PaymentPort আর OrderRepository দুটি driven port — Python-এর typing.Protocol দিয়ে লেখা (Python-এ Protocol দেখুন)। PlaceOrder use case শুধু এই দুটি নাম জানে। প্রতিটি port-এর দুটি adapter: memory-তে চলা test adapter, আর একটি “production” adapter, যা আসল database-এর বদলে SQL statement ছাপায় (চালানোর যন্ত্রে database নেই, তাই এটি একটি খেলনা)। একই use case দুই জোড়া adapter দিয়ে চালানো হলো।

from dataclasses import dataclass
from typing import Protocol
@dataclass
class Order:                                   # domain entity
    id: int; customer: str; amount: int; status: str = "NEW"
class PaymentPort(Protocol):                   # driven ports, owned by the core
    def charge(self, customer: str, amount: int) -> bool: ...
class OrderRepository(Protocol):
    def save(self, order: Order) -> None: ...
class PlaceOrder:                              # use case: imports no adapter
    def __init__(self, pay: PaymentPort, repo: OrderRepository): self.pay, self.repo = pay, repo
    def run(self, oid, customer, amount):
        order = Order(oid, customer, amount)
        order.status = "PAID" if self.pay.charge(customer, amount) else "REJECTED"
        self.repo.save(order)
        return order.status
class InMemoryPayment:                         # test adapters
    def __init__(self, wallet): self.wallet = wallet
    def charge(self, c, amt):
        if self.wallet.get(c, 0) < amt: return False
        self.wallet[c] -= amt; return True
class InMemoryOrders(dict):
    def save(self, o): self[o.id] = o.status
class SqlPayment:                              # "production" adapters (fake SQL)
    def charge(self, c, amt):
        print(f"  SQL> UPDATE wallet SET bal = bal - {amt} WHERE cust = '{c}' AND bal >= {amt}")
        return amt <= 1000                     # pretend the DB answered
class SqlOrders:
    def save(self, o): print(f"  SQL> INSERT INTO orders VALUES ({o.id}, '{o.customer}', {o.amount}, '{o.status}')")
rows = InMemoryOrders()
test_uc = PlaceOrder(InMemoryPayment({"rina": 500}), rows)
print("test:", test_uc.run(1, "rina", 300), test_uc.run(2, "rina", 300), rows)
prod_uc = PlaceOrder(SqlPayment(), SqlOrders())
for oid, amt in ((3, 800), (4, 1500)): print("prod:", prod_uc.run(oid, "karim", amt))

test: PAID REJECTED {1: 'PAID', 2: 'REJECTED'}
  SQL> UPDATE wallet SET bal = bal - 800 WHERE cust = 'karim' AND bal >= 800
  SQL> INSERT INTO orders VALUES (3, 'karim', 800, 'PAID')
prod: PAID
  SQL> UPDATE wallet SET bal = bal - 1500 WHERE cust = 'karim' AND bal >= 1500
  SQL> INSERT INTO orders VALUES (4, 'karim', 1500, 'REJECTED')
prod: REJECTED

৩ · Onion আর Clean Architecture — বৃত্ত আর dependency rule

Hexagon-এর পরে এল বৃত্তের ছবি। ২০০৮ সালে Jeffrey Palermo কয়েকটি blog লেখায় onion architecture নাম দেন (সাধারণত এভাবেই উল্লেখ করা হয়): পেঁয়াজের মতো স্তর — একেবারে মাঝে domain model, তার চারপাশে domain service, তারপর application service, আর সবচেয়ে বাইরে UI, infrastructure আর test. তাঁর মূল দাবি: সব নির্ভরতা কেন্দ্রের দিকে, database কেন্দ্রে নয় বরং বাইরের একটি খুঁটিনাটি।

২০১২ সালের আগস্টে Robert C. Martin “The Clean Architecture” নামে একটি blog লেখা প্রকাশ করেন, আর ২০১৭ সালে একই নামের বই (Clean Architecture: A Craftsman's Guide to Software Structure and Design). Blog-এ তিনি নিজেই বলেন, এটি নতুন আবিষ্কার নয়; hexagonal, onion, Jacobson-এর BCE (boundary-control-entity) আর আরও কয়েকটি ধারণার সাধারণ সূত্রকে একটি নিয়মে বাঁধার চেষ্টা। Clean Architecture-এর চারটি বৃত্ত, ভেতর থেকে বাইরে:

বৃত্তগুলোর ওপর একটিই আইন, যার নাম dependency rule: source code-এর নির্ভরতা শুধু ভেতরের দিকে যেতে পারে। ভেতরের বৃত্তের কোনো কিছু বাইরের বৃত্তের কোনো কিছুর নাম জানবে না — class, function, variable, এমনকি data-র format-ও নয়। Martin এটাও বলেন যে চারটি বৃত্ত একটি নমুনা, আইন নয়; বৃত্ত বেশি-কম হতে পারে, কিন্তু নির্ভরতার দিক বদলায় না।

এই নিয়মটি যন্ত্র দিয়েও যাচাই করা যায় — import-এর তালিকা দেখে। নিচের stepper একটি ছোট project-এর ছয়টি import পরপর পরীক্ষা করছে। প্রতিটি module-এর একটি ring নম্বর (০ = entities, ৩ = frameworks). নিয়ম: কোনো module নিজের চেয়ে বড় নম্বরের ring-কে import করবে না; আর বাইরের library (ORM, web framework) import করতে পারবে শুধু ring ২ আর ৩।

1// domain/order.js            (ring 0)2import { Money } from "./money.js"3import { Column } from "lib/orm"4// app/placeOrder.js          (ring 1)5import { OrderRepository } from "./ports.js"6import { SqlOrderRepo } from "../adapters/sqlOrderRepo.js"7// adapters/orderController.js (ring 2)8import { PlaceOrder } from "../app/placeOrder.js"9// adapters/sqlOrderRepo.js    (ring 2)10import { OrderRepository } from "../app/ports.js"

// Dependency-rule checker. Ring 0 = innermost (entities), 3 = outermost.
const ring = {
  "domain/money": 0, "domain/order": 0,
  "app/ports": 1, "app/placeOrder": 1,
  "adapters/orderController": 2, "adapters/orderDto": 2, "adapters/sqlOrderRepo": 2,
  "web/server": 3, "main": 3,
};
const libs = new Set(["lib/orm", "lib/web"]);   // third-party: only rings 2-3 may import
const imports = {
  "domain/money": [],
  "domain/order": ["domain/money", "lib/orm"],
  "app/ports": ["domain/order"],
  "app/placeOrder": ["app/ports", "domain/order", "adapters/sqlOrderRepo", "adapters/orderDto"],
  "adapters/orderController": ["app/placeOrder", "adapters/orderDto"],
  "adapters/orderDto": [],
  "adapters/sqlOrderRepo": ["app/ports", "domain/order", "lib/orm"],
  "web/server": ["adapters/orderController", "lib/web"],
  "main": ["web/server", "adapters/sqlOrderRepo", "app/placeOrder"],
};
const names = ["entities", "use cases", "adapters", "frameworks"];
let edges = 0;
const bad = [];
for (const [from, tos] of Object.entries(imports)) {
  for (const to of tos) {
    edges++;
    const outward = libs.has(to) ? ring[from] < 2 : ring[to] > ring[from];
    if (outward) bad.push([from, to]);
  }
}
console.log("edges checked:", edges, "| violations:", bad.length);
for (const [from, to] of bad) {
  const where = libs.has(to) ? "library" : names[ring[to]];
  console.log(`  OUTWARD ${from} (${names[ring[from]]}) -> ${to} (${where})`);
}
console.log("allowed edges:", edges - bad.length);

edges checked: 17 | violations: 3
  OUTWARD domain/order (entities) -> lib/orm (library)
  OUTWARD app/placeOrder (use cases) -> adapters/sqlOrderRepo (adapters)
  OUTWARD app/placeOrder (use cases) -> adapters/orderDto (adapters)
allowed edges: 14

৪ · Boundary পার হওয়া — DIP আর DTO

Dependency rule শুনে প্রথম প্রশ্ন আসে: use case-কে তো ফল দেখাতে হবে, database-এ লিখতে হবে — বাইরের কাউকে না চিনে সে বাইরে ডাকবে কীভাবে? উত্তর দুটি সরঞ্জামে।

ডাকের দিক উল্টানো — interface ভেতরে, বাস্তবায়ন বাইরে

Use case যখন বাইরে কিছু করাতে চায়, সে নিজের বৃত্তে একটি interface ঘোষণা করে — OrderRepository, PaymentPort, বা ফল দেখানোর জন্য একটি output port (Martin-এর ছবিতে “Use Case Output Port”, যা বাস্তবায়ন করে presenter). বাইরের adapter সেই interface বাস্তবায়ন করে। ফলে flow of control বাইরের দিকে যায়, কিন্তু source dependency ভেতরের দিকে থাকে। এটি হুবহু পর্ব ২৮-এর DIP: abstraction-এর মালিক policy, detail তার সাথে মানিয়ে নেয়। আর আসল adapter কে বানিয়ে use case-কে দেবে? Composition root — app-এর সবচেয়ে বাইরের main (পর্ব ৩৭)। সেজন্যই composition root সবচেয়ে বাইরের বৃত্তে থাকে: একমাত্র সেখানেই সবার নাম জানা বৈধ।

সীমানা পেরোয় শুধু সরল data — DTO

দ্বিতীয় প্রশ্ন: সীমানা পেরিয়ে কোন রূপে data যাবে? Martin-এর উত্তর: সরল data structure — সাধারণ object, dictionary বা function-এর argument. এদের বলা হয় DTO (data transfer object). যা যাবে না: ORM-এর row object (তাতে database-এর জ্ঞান লুকিয়ে থাকে), web framework-এর request object, বা অনেক সময় entity নিজেও (তাহলে বাইরের বৃত্ত entity-র ভেতরের খুঁটিনাটির ওপর নির্ভর করবে)।

@dataclass(frozen=True)
class PlaceOrderInput:                     # owned by the use-case ring
    customer: str
    amount: int

@dataclass(frozen=True)
class PlaceOrderOutput:                    # also owned by the use-case ring
    order_id: int
    status: str

class PlaceOrderPresenter(Protocol):       # output port; a presenter implements it
    def present(self, out: PlaceOrderOutput) -> None: ...

class PlaceOrder:
    def __init__(self, pay, repo, presenter: PlaceOrderPresenter):
        self.pay, self.repo, self.presenter = pay, repo, presenter
    def run(self, cmd: PlaceOrderInput) -> None:
        order = Order(self.repo.next_id(), cmd.customer, cmd.amount)
        order.status = "PAID" if self.pay.charge(cmd.customer, cmd.amount) else "REJECTED"
        self.repo.save(order)
        self.presenter.present(PlaceOrderOutput(order.id, order.status))

class JsonPresenter:                       # interface-adapters ring
    def present(self, out):
        self.body = {"id": out.order_id, "status": out.status}

উদাহরণটিতে PlaceOrderInput আর PlaceOrderOutput দুটিই use case-এর বৃত্তে, কারণ use case তাদের মালিক। Controller HTTP body থেকে PlaceOrderInput বানায়; presenter PlaceOrderOutput পেয়ে ঠিক করে সেটি JSON হবে, HTML হবে, না SMS-এর লেখা। Use case জানে না ফল কোথায় দেখানো হবে।

৫ · তিনটি নাম, একটি মূল ধারণা

পরীক্ষা আর ইন্টারভিউতে প্রায়ই জিজ্ঞাসা করা হয়: hexagonal, onion আর Clean — পার্থক্য কী? সৎ উত্তর হলো: মূল ধারণা একই — business-এর নিয়ম কেন্দ্রে, খুঁটিনাটি বাইরে, নির্ভরতা ভেতরের দিকে। পার্থক্য মূলত ছবিতে, শব্দে আর কোন দিকে জোর দেওয়া হয়েছে তাতে।

একটি কাজের তুলনা: hexagonal বলে core-এর সীমানা কেমন হবে, Clean বলে সীমানার ভেতরে কী কী স্তর থাকবে, আর onion দুটির মাঝামাঝি। বাস্তবের অনেক codebase তিনটির শব্দ মিশিয়ে ব্যবহার করে — “use case” Clean থেকে, “port/adapter” hexagonal থেকে। এতে ভুল কিছু নেই, যদি দল একই শব্দে একই জিনিস বোঝে।

৬ · Domain-driven design-এর মূল কথা

Hexagonal আর Clean বলে core কোথায়, কিন্তু core-এর ভেতরটা কীভাবে সাজাবেন, তা প্রায় বলে না। এই শূন্যতা পূরণ করে domain-driven design (DDD) — Eric Evans-এর ২০০৩ সালের বই Domain-Driven Design: Tackling Complexity in the Heart of Software. পরে Vaughn Vernon-এর Implementing Domain-Driven Design (২০১৩) অনেক ব্যবহারিক নিয়ম যোগ করে। DDD-র মূল দাবি: জটিল software-এর আসল কঠিন অংশ প্রযুক্তি নয়, ব্যবসার জ্ঞান — তাই নকশা শুরু হোক domain থেকে, domain expert-দের সাথে বসে।

Ubiquitous language — দল আর কোডের এক ভাষা

Ubiquitous language মানে domain expert, developer আর কোড — সবাই একই শব্দ একই অর্থে ব্যবহার করবে। দোকানের হিসাবরক্ষক যদি বলেন “বাকির খাতা”, কোডে CreditLedger থাকুক, tbl_cust_bal2 নয়। কোনো শব্দ নিয়ে আলোচনায় বিভ্রান্তি দেখা দিলে সেটি নকশার সমস্যার সংকেত। পর্ব ২৩-এর domain model আর domain glossary এখানে কোডে রূপ নেয়।

Entity বনাম value object

Value object-এর অভাবে একটি পরিচিত ভুল হয়, যার নাম primitive obsession: টাকা, ফোন নম্বর, তারিখ — সবকিছু সাধারণ int বা str. তখন টাকার সাথে ডলার যোগ হয়ে যায়, আর কেউ টেরও পায় না (code smell হিসেবে এটি আবার আসবে পর্ব ৪২-এ)। ১৯৯৯ সালে Mars Climate Orbiter হারানোর তদন্তে একটি কারণ হিসেবে উঠে আসে যে এক দলের software ইম্পেরিয়াল একক (pound-force second) আর আরেক দল metric একক (newton second) ধরে নিয়েছিল — সংখ্যা ছিল, একক ছিল না। নিচের কোডে প্রথমে সেই ভুল, তারপর Money value object, তারপর একটি aggregate.

Aggregate আর invariant

Aggregate হলো কয়েকটি entity আর value object-এর একটি গুচ্ছ, যা একসাথে একটি নিয়ম (invariant) রক্ষা করে, আর বাইরে থেকে যাকে একটি একক হিসেবে বদলানো হয়। গুচ্ছের প্রবেশদ্বার একটি entity — aggregate root. Order একটি aggregate root; তার order line-গুলো তার ভেতরে। “মোট দাম ≤ credit limit” — এই invariant রক্ষা করা Order-এর দায়, কারণ শুধু Order-ই সব line একসাথে দেখে। বাইরের কোড line-এর list-এ সরাসরি হাত দেবে না; সব বদল root-এর method দিয়ে।

from dataclasses import dataclass, FrozenInstanceError
cart_taka, shipping_dollar = 500, 5             # primitive obsession: bare ints
print("primitive total:", cart_taka + shipping_dollar)   # silently wrong
@dataclass(frozen=True)
class Money:                                    # value object
    amount: int                                 # whole units, for simplicity
    currency: str
    def __add__(self, other):
        if self.currency != other.currency:
            raise ValueError(f"cannot add {self.currency} and {other.currency}")
        return Money(self.amount + other.amount, self.currency)
    def times(self, n): return Money(self.amount * n, self.currency)
print("equal by value:", Money(500, "BDT") == Money(500, "BDT"))
try: Money(500, "BDT") + Money(5, "USD")
except ValueError as e: print("Money says:", e)
try: Money(500, "BDT").amount = 1
except FrozenInstanceError: print("Money is immutable")
class Order:                                    # aggregate root
    def __init__(self, oid, credit_limit):
        self.id, self.limit, self._lines = oid, credit_limit, []
    def total(self):
        t = Money(0, self.limit.currency)
        for sku, price, qty in self._lines: t = t + price.times(qty)
        return t
    def add_line(self, sku, price, qty):        # the only way in
        new_total = self.total() + price.times(qty)
        if new_total.amount > self.limit.amount:
            raise ValueError(f"credit limit {self.limit.amount} < {new_total.amount}")
        self._lines.append((sku, price, qty))
o = Order(7, Money(2000, "BDT"))
o.add_line("rice-5kg", Money(650, "BDT"), 2)
try: o.add_line("oil-5l", Money(900, "BDT"), 1)
except ValueError as e: print("rejected:", e)
print("total:", o.total(), "| lines:", len(o._lines))

primitive total: 505
equal by value: True
Money says: cannot add BDT and USD
Money is immutable
rejected: credit limit 2000 < 2200
total: Money(amount=1300, currency='BDT') | lines: 1

নিচের stepper-এ একই Order aggregate-এর ওপর পাঁচটি command, আর শেষে সংরক্ষণ। প্রতিটি command হয় পুরোপুরি গৃহীত, নয় পুরোপুরি প্রত্যাখ্যাত — মাঝামাঝি কিছু নেই।

Repository, domain service আর domain event

• Repository: প্রতিটি aggregate root-এর জন্য একটি repository — একটি collection-এর মতো interface (save, get(id)), যার পেছনে database লুকানো। Hexagonal-এর ভাষায় এটি একটি driven port; Git-এর “repository”-র সাথে নামের মিল কাকতালীয়।
• Domain service: যে নিয়ম কোনো একটি entity-র স্বাভাবিক দায় নয় — যেমন দুটি wallet-এর মধ্যে টাকা স্থানান্তর — তা একটি stateless service-এ। সতর্কতা: সব নিয়ম service-এ ঠেলে দিলে entity ফাঁপা হয়ে যায় (পরের অংশ)।
• Domain event: domain-এ ঘটে যাওয়া একটি অর্থবহ ঘটনা, অতীত কালে নাম: OrderPlaced, PaymentRejected. অন্য অংশ (SMS পাঠানো, stock কমানো) এতে সাড়া দেয়, Order-কে তাদের চিনতে হয় না — পর্ব ৩৫-এর observer-এর বড় রূপ। Evans-এর মূল বইয়ে এটি building block হিসেবে প্রধান ছিল না; পরে DDD সমাজে এটি কেন্দ্রীয় হয়ে ওঠে বলে সাধারণত বলা হয়। Event দিয়ে পুরো অবস্থা রাখার কৌশল দেখুন System Design-এর event sourcing পর্বে।

Bounded context আর context map

একটি বড় প্রতিষ্ঠানে একই শব্দের অর্থ বিভাগভেদে আলাদা। মুদি-বাজারের বিক্রয় বিভাগে “product” মানে ছবি, দাম আর বিবরণ; গুদামে “product” মানে তাক নম্বর, ওজন আর মজুত। সবার জন্য একটিই বিশাল Product class বানালে সেটি কারও কাজের হয় না। DDD-র উত্তর bounded context: একটি স্পষ্ট সীমানা, যার ভেতরে একটি model আর একটি ভাষা সুসংগত। বিভিন্ন context-এর সম্পর্ক আঁকা হয় একটি context map-এ — কে কার কাছ থেকে data নেয় (customer/supplier), কে অন্যের model হুবহু মেনে নেয় (conformist), কোথায় অনুবাদের জন্য anti-corruption layer, কোথায় দুই দল একটি ছোট model ভাগ করে (shared kernel). Service-এর মাপে এই সীমানা কীভাবে microservice-এর সীমানা হয়, তা দেখুন System Design-এর microservices পর্বে; এখানে শুধু এটুকু মনে রাখুন: একটি codebase-এর ভেতরেও bounded context আলাদা module বা package হতে পারে।

৭ · Anemic বনাম rich domain model

২০০৩ সালে Martin Fowler তাঁর bliki-তে একটি লেখায় anemic domain model-কে একটি anti-pattern বলেন (লেখাটি সাধারণত এভাবেই উদ্ধৃত হয়)। লক্ষণ: domain object-গুলো দেখতে আসল — Order, Customer, getter-setter সব আছে — কিন্তু ভেতরে কোনো আচরণ নেই; সব নিয়ম থাকে আলাদা “service” class-এ। Fowler-এর আপত্তি: object-oriented নকশার মূল কথা — data আর তার ওপরের আচরণ একসাথে — বাদ পড়ে যায়, অথচ domain model-এর সব খরচ (mapping, স্তর) ঠিকই দিতে হয়। এর বিপরীত rich domain model: নিয়ম থাকে data-র পাশে, object নিজের invariant নিজে রক্ষা করে।

সবচেয়ে বড় ঝুঁকিটি হলো invariant “চুইয়ে বেরিয়ে যাওয়া”। নিচে একই নিয়ম (“মোট ≤ ২০০০”) দুইভাবে।

// Same rule, two models: order total must never exceed the credit limit.
const total = lines => lines.reduce((s, l) => s + l.price * l.qty, 0);
// ANEMIC: a data bag; the rule lives in a service that callers may skip.
const anemic = { limit: 2000, lines: [] };
const OrderService = {
  addLine(o, sku, price, qty) {
    if (total(o.lines) + price * qty > o.limit) throw new Error("limit exceeded");
    o.lines.push({ sku, price, qty });
  },
};
OrderService.addLine(anemic, "rice", 650, 2);
anemic.lines.push({ sku: "oil", price: 900, qty: 1 }); // an import script skips the service
anemic.lines[0].qty = 4;                               // a "quick fix" elsewhere
console.log("anemic total:", total(anemic.lines), "| broken:", total(anemic.lines) > anemic.limit);
// RICH: the data is private; every change goes through a guarded method.
class Order {
  #lines = []; #limit;
  constructor(limit) { this.#limit = limit; }
  #commit(next) {
    if (total(next) > this.#limit) throw new Error(`limit ${this.#limit} < ${total(next)}`);
    this.#lines = next;
  }
  addLine(sku, price, qty) { this.#commit([...this.#lines, { sku, price, qty }]); }
  changeQty(sku, qty) { this.#commit(this.#lines.map(l => (l.sku === sku ? { ...l, qty } : l))); }
  get total() { return total(this.#lines); }
  get lines() { return this.#lines.map(l => ({ ...l })); }    // copies only
}
const rich = new Order(2000);
rich.addLine("rice", 650, 2);
for (const cmd of [() => rich.addLine("oil", 900, 1), () => rich.changeQty("rice", 4)]) {
  try { cmd(); } catch (e) { console.log("rich rejected:", e.message); }
}
rich.lines.push({ sku: "oil", price: 900, qty: 1 });  // pushes into a copy
rich.lines[0].qty = 4;                                // edits a copy
console.log("rich total:", rich.total, "| lines:", rich.lines.length);

anemic total: 3500 | broken: true
rich rejected: limit 2000 < 2200
rich rejected: limit 2000 < 2600
rich total: 1300 | lines: 1

৮ · দাম, আর কখন ব্যবহার করবেন

এই পর্বের architecture-গুলো বিনামূল্যে আসে না। তিনটি দাম সবসময় দিতে হয়:

• Indirection: “Save চাপলে কী হয়?” — উত্তর খুঁজতে controller থেকে use case, use case থেকে port, port থেকে… কোন adapter? সেটি জানতে composition root-এ যেতে হয়। IDE-র “go to definition” আপনাকে interface-এ নিয়ে থামে।
• বেশি file আর mapping: একটি feature-এ controller, input DTO, use case, port, adapter, mapper, output DTO, presenter — সহজেই ৮টি file, যেখানে সরল নকশায় ২টি। প্রতিটি সীমানায় field-গুলো আবার লেখা।
• CRUD app-এ over-engineering: যদি app-এর কাজ শুধু form থেকে পড়ে table-এ লেখা আর table থেকে পড়ে দেখানো (CRUD), তাহলে কেন্দ্রে রক্ষা করার মতো নিয়ম প্রায় নেই। চার বৃত্ত তখন শুধু একই data-কে চারবার হাতবদল করে।

একটি বাস্তব মাঝামাঝি পথ: সব জায়গায় চার বৃত্ত নয়, বরং ঝুঁকির জায়গায় একটি port. যেমন payment gateway বাইরের, অস্থির আর test-এ বিপজ্জনক — শুধু তার জন্য একটি PaymentPort আর দুটি adapter. বাকি CRUD অংশ framework-এর সাধারণ পথে। নিয়ম জটিল হতে থাকলে, অংশটি ধীরে ধীরে core-এ সরানো যায় — পর্ব ৪৩-এর পুরোনো কোড সামলানোর কৌশলের মতো ছোট ধাপে। পরিচ্ছন্ন নাম আর ছোট function (পর্ব ৪১) যেকোনো architecture-এ লাগে; architecture সেগুলোর বিকল্প নয়।

৯ · AI-এর যুগে architecture আর DDD

AI-কে “এই project Clean Architecture-এ সাজিয়ে দাও” বললে সে প্রায়ই চমৎকার দেখতে একটি folder-গাছ দেয় — আর ভুলগুলো থাকে ভেতরে। কয়েকটি সাধারণ ভুল আর ধরার উপায়:

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

• Core-এর (entities, use cases) কোনো file-এ framework, ORM, HTTP বা SQL-এর import নেই — নিজে খুঁজে বা checker চালিয়ে দেখেছি
• প্রতিটি port core-এর বৃত্তে, core-এর ভাষায়; প্রতিটি port-এর অন্তত একটি test adapter আছে
• প্রতিটি নতুন স্তর বা interface-এর পেছনে একটি বাস্তব কারণ (নিয়ম, দ্বিতীয় বাস্তবায়ন, test) লিখে রাখতে পেরেছি; না পারলে বাদ দিয়েছি
• Aggregate-এর invariant ভাঙার চেষ্টা করে এমন test লিখেছি, আর সেটি প্রত্যাখ্যান পেয়েছে
• নতুন test ইচ্ছা করে ভাঙা নিয়মে চালিয়ে দেখেছি যে সত্যিই ফেল করে
• বদলগুলো আলাদা branch-এ ছোট commit-এ, pull request হিসেবে review করিয়েছি (পর্ব ১৬, পর্ব ৪৪)
• AI-এর উল্লেখ করা বই, সাল বা tool-এর নাম মূল উৎসে মিলিয়েছি; কপি করা কোডের licence নিয়ে সন্দেহ হলে যাচাই করেছি