Architecture Diagram ও ADR: সিদ্ধান্তের কারণ লিখে রাখা
Architecture Diagrams and ADRs
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Context, container ও sequence diagram আলাদা করা
- Architecture Decision Record দিয়ে সিদ্ধান্ত সংরক্ষণ
- Laravel প্রকল্পে নকশা ও code মিলিয়ে রাখা
সমস্যা দিয়ে শুরু
একটি দোকানের notification প্রথমে request-এর মধ্যেই যেত। পরে queue যোগ হলো, কিন্তু README-তে এখনো synchronous flow। নতুন developer পুরোনো diagram দেখে timeout বাড়ালেন; আসল সমস্যা ছিল worker বন্ধ। Architecture document কাজে লাগে তখনই, যখন পাঠক তার scope, তারিখ এবং সিদ্ধান্তের কারণ বুঝতে পারেন। সুন্দর বাক্স আঁকলেই system বোঝানো শেষ হয় না।
সহজ করে বুঝি
Architecture diagram হলো নির্দিষ্ট প্রশ্নের উত্তর দেওয়ার সংক্ষিপ্ত মানচিত্র। Context diagram-এ user ও external system, container diagram-এ deployable application ও data store, sequence diagram-এ সময় অনুযায়ী interaction দেখান। এখানে container মানে শুধু Docker container নয়। ADR একটি সিদ্ধান্তের ছোট নথি: context, options, decision, consequences ও status। কেন বিকল্পটি বাদ গেল সেটিও ভবিষ্যতের জন্য গুরুত্বপূর্ণ। প্রতিটি method diagram-এ ঢোকালে পাঠক মূল boundary হারান।
পরিচিত একটি উপমা
বাড়ির নকশায় এলাকায় অবস্থান, তলার layout এবং বিদ্যুতের wiring আলাদা পাতায় থাকে। রান্নাঘর খুঁজতে wiring diagram লাগে না। একইভাবে product manager-এর context map আর developer-এর checkout sequence একই detail-এর হওয়া উচিত নয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD U[Customer] --> A[Laravel Store] A --> D[(PostgreSQL)] A --> Q[(Order Queue)] Q --> W[Notification Worker] W --> P[Mail Provider]
Customer থেকে Laravel-এ arrow request বোঝায়। Database arrow durable order write, queue arrow asynchronous handoff। Worker external mail provider ডাকে; user response সেই provider-এর অপেক্ষায় থাকার দরকার নেই। Diagram-এ commit ও dispatch-এর সুনির্দিষ্ট সময় নেই, তাই সেই race বোঝাতে আলাদা sequence বা note দিন। Trust boundary ও ownership লিখলে failure আলোচনা সহজ হয়।
PHP ও Laravel-এ প্রয়োগ
নিচের action fragment order transaction ও afterCommit handoff দেখায়। Order model, user ও SendOrderReceipt queue job আগে থেকে আছে; fillable configuration এবং async queue worker দরকার। এটি ADR-এর সিদ্ধান্তকে code-এর সঙ্গে মেলানোর উদাহরণ, সম্পূর্ণ checkout নয়।
use App\Jobs\SendOrderReceipt;
use App\Models\Order;
use Illuminate\Support\Facades\DB;
$order = DB::transaction(function () use ($user) {
$order = Order::create([
'user_id' => $user->id,
'status' => 'pending',
]);
SendOrderReceipt::dispatch($order->id)->afterCommit();
return $order;
});সুবিধা, সীমাবদ্ধতা ও trade-off
ছোট ADR review দ্রুত করে এবং আগের বিতর্ক আবার করতে হয় না। তবে প্রতিটি variable-এর জন্য ADR লিখলে নথির খরচ বাড়ে। Data ownership, broker নির্বাচন বা consistency boundary-এর মতো দীর্ঘস্থায়ী সিদ্ধান্ত আগে লিখুন। Diagram implementation থেকে দূরে সরে গেলে ভুল আত্মবিশ্বাস তৈরি করে; architecture পরিবর্তনের pull request-এই সংশ্লিষ্ট নথি বদলান।
সাধারণ ভুল
- Arrow-তে protocol, sync/async বা data direction না বোঝানো।
- Vendor logo দিয়ে business responsibility আড়াল করা।
- বাতিল সিদ্ধান্ত মুছে ফেলে তার কারণ হারানো।
আরও একটু গভীরে
ADR-এ proposed, accepted, superseded status রাখা যায়। নতুন সিদ্ধান্তে পুরোনোটির link দিন; ইতিহাস পুনর্লিখন করবেন না। Queue বেছে নেওয়ার consequence হিসেবে retry, idempotency ও observability লিখুন। afterCommit commit-এর আগে job processing ঠেকাতে সাহায্য করে, কিন্তু commit থেকে broker publish-এর crash gap বন্ধ করে না। Durable delivery অপরিহার্য হলে outbox-এর আলাদা সিদ্ধান্ত লাগবে।
মনে রাখুন
এক diagram এক ধরনের প্রশ্নের উত্তর দিক। সিদ্ধান্তের সঙ্গে কারণ, সীমা ও পরিবর্তনের তারিখ রাখুন। Documentation code review-এর অংশ হলে বেশি নির্ভরযোগ্য থাকে।
নিজে চেষ্টা করুন
একটি Laravel দোকানের synchronous email থেকে queued email-এ যাওয়ার ADR লিখুন। অন্তত দুইটি option, failure scenario, rollback plan এবং diagram-এ বাদ দেওয়া detail উল্লেখ করুন।
নিজের বোঝা যাচাই করুন
1. Context ও sequence diagram কীভাবে আলাদা?
Context-এ system boundary ও actor দেখা যায়। Sequence-এ interaction-এর সময়ক্রম দেখা যায়; একটি থেকে অন্যটির ordering অনুমান করা ঠিক নয়।
2. সব class architecture diagram-এ লাগবে?
না। পাঠকের প্রশ্ন অনুযায়ী abstraction বেছে নিন। অত্যধিক detail মূল database ও deployment boundary অস্পষ্ট করে।
3. ADR শুধু কী বেছে নিয়েছি?
না। Constraints, alternatives ও consequences না থাকলে ভবিষ্যতের developer বদলে যাওয়া পরিস্থিতিতে সিদ্ধান্ত বিচার করতে পারবেন না।
4. afterCommit কি reliable broker publish নিশ্চিত করে?
না। Commit-এর পরে process crash হলে publish বাদ পড়তে পারে। Stronger handoff দরকার হলে transactional outbox বিবেচনা করুন।
5. পুরোনো ADR ভুল হলে মুছব?
সাধারণত superseded status ও নতুন ADR-এর link দিন। এতে কোন context-এ আগের সিদ্ধান্ত যুক্তিসংগত ছিল বোঝা যায়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।