১৪ এপ্রি, ২০২৫·8 মিনিট
কিভাবে মাইক্রোফ্রেমওয়ার্কগুলো নমনীয় কাস্টম আর্কিটেকচার সক্ষম করে
জানুন কীভাবে মাইক্রোফ্রেমওয়ার্কগুলো টিমকে পরিষ্কার মডিউল, মিডলওয়্যার এবং বাউন্ডারি নিয়ে কাস্টম আর্কিটেকচার গঠন করতে দেয়—সাথে ট্রেড‑অফ, প্যাটার্ন ও সতর্কতা।
জানুন কীভাবে মাইক্রোফ্রেমওয়ার্কগুলো টিমকে পরিষ্কার মডিউল, মিডলওয়্যার এবং বাউন্ডারি নিয়ে কাস্টম আর্কিটেকচার গঠন করতে দেয়—সাথে ট্রেড‑অফ, প্যাটার্ন ও সতর্কতা।
মাইক্রোফ্রেমওয়ার্কগুলো হাল্কা ওয়েব ফ্রেমওয়ার্ক যা অপরিহার্য বিষয়গুলোর উপর ফোকাস করে: একটি রিকোয়েস্ট নেওয়া, তা সঠিক হ্যান্ডলারে রাউট করা, এবং একটি রেসপন্স ফেরত দেওয়া। ফুল‑স্ট্যাক ফ্রেমওয়ার্কের মতো সবকিছু একসাথে বেঁধে দেয় না (অ্যাডমিন প্যানেল, ORM/ডেটাবেস লেয়ার, ফর্ম বিল্ডার, ব্যাকগ্রাউন্ড জব, অথেনটিকেশন ফ্লো ইত্যাদি)। বদলে, এগুলো একটি ছোট, স্থিতিশীল কোর দেয় এবং আপনি শুধু আপনার প্রোডাক্টের জন্য প্রয়োজনীয় অংশগুলো যোগ করবেন।
একটি ফুল‑স্ট্যাক ফ্রেমওয়ার্ক এমন, যেন আপনি একটি পুরো প্রস্তুত‑সজ্জিত ঘর কিনেছেন: উপযোগী, অথচ রিমডেল করা কঠিন। একটি মাইক্রোফ্রেমওয়ার্ক বেশি মিল রাখে খালি‑তবে‑স্ট্রাকচার্ড স্পেসের সাথে: আপনি ঘরের কক্ষ, আসবাবপত্র এবং ইউটিলিটিজ ঠিক করবেন।
এই স্বাধীনতাকেই আমরা কাস্টম আর্কিটেকচার বলি—আর্টিফ্যাক্ট যা আপনার টিমের প্রয়োজন, ডোমেইন, এবং অপারেশনাল সীমাবদ্ধতা অনুসারে গঠিত। সরলভাবে: আপনি নির্ধারণ করেন কোন কম্পোনেন্ট (লগিং, ডাটাবেস অ্যাক্সেস, ভ্যালিডেশন, অথ, ব্যাকগ্রাউন্ড প্রসেসিং) লাগবে এবং সেগুলো কীভাবে যুক্ত হবে—একটি নির্ধারিত “একটাই সঠিক পথ” গ্রহণ করার বদলে।
টিমগুলো প্রায়ই মাইক্রোফ্রেমওয়ার্ক বেছে নেয় যখন তারা চায়:
আমরা মডুলার ডিজাইন সমর্থনের উপর ফোকাস করব: বিল্ডিং ব্লকগুলো কিভাবে কম্পোজ করা হয়, মিডলওয়্যার কিভাবে ব্যবহার করা হয়, এবং ডিপেন্ডেন্সি ইনজেকশন যোগ করা যায় এমনভাবে যাতে প্রোজেক্ট একটি বিজ্ঞান পরীক্ষায় পরিণত না হয়।
এটিতে কোনো নির্দিষ্ট ফ্রেমওয়ার্ক লাইন‑বাই‑লাইন তুলনা থাকবে না এবং না দাবী করা হবে যে মাইক্রোফ্রেমওয়ার্ক সর্বদা ভাল। লক্ষ্য হলো আপনাকে স্ট্রাকচার সচেতনভাবে বেছে নিতে সাহায্য করা—এবং প্রয়োজন বদলে গেলে নিরাপদে সেটি বিবর্তিত করা।
মাইক্রোফ্রেমওয়ার্ক তখনই সবচেয়ে ভালো কাজ করে যখন আপনি আপনার অ্যাপকে একটি কিট হিসেবে দেখেন, কোনো প্রি‑বিল্ট হাউস হিসেবে নয়। একটি অপিনিয়ন্ড স্ট্যাক গ্রহণ করার বদলে, আপনি একটি ছোট কোর নিয়ে শুরু করেন এবং সেই বৈশিষ্ট্যই যোগ করেন যখন সেগুলো বাস্তবে কাজে আসে।
একটি বাস্তবসম্মত “কোর” সাধারণত কেবল:
এগুলি দিয়েই একটি কাজ করা API এন্ডপয়েন্ট বা ওয়েব পেজ শিপ করা সম্ভব। বাকিগুলো তখনই যোগ করুন যখন কার্যকারিতার সুস্পষ্ট কারণ থাকে।
অবশ্যই যখন আপনাকে অথেনটিকেশন, ভ্যালিডেশন, বা লগিং লাগবে—তখন সেগুলো আলাদা কম্পোনেন্ট হিসেবে যোগ করুন—আইনটির পেছনে পরিষ্কার ইন্টারফেস থাকা উচিৎ। এতে আর্কিটেকচার বোধগম্য থাকে: প্রতিটি নতুন অংশের কি সমস্যার সমাধান আছে এবং সেটা কোথায় প্লাগ ইন হবে তা বোঝা যায়।
“প্রয়োজন অনুযায়ী যোগ করুন” মডিউলের উদাহরণ:
শুরুতে এমন সমাধান বেছে নিন যা আপনাকে আটকে রাখে না। ডিপ ফ্রেমওয়ার্ক ম্যাজিকের বদলে পাতলা র্যাপার ও কনফিগারেশন বেছে নিন। যদি একটি মডিউল বদলাতে পারছেন কোনো বড়‑বিজনেস লজিক পুনর্লিখা ছাড়া, তাহলে আপনি সঠিক পথে আছেন।
কোনো আর্কিটেকচার পছন্দের জন্য একটি সহজ “ডান হয়েছে” সংজ্ঞা: টিম প্রতিটি মডিউলের উদ্দেশ্য ব্যাখ্যা করতে পারে, এক‑দুই দিনে তা প্রতিস্থাপন করতে পারে, এবং আলাদা ভাবে টেস্ট করা যায়।
মাইক্রোফ্রেমওয়ার্কগুলো ডিজাইনে ছোট থাকে, যার মানে আপনি অ্যাপের “অর্গান” নিজে বেছে নিতে পারেন—ফ্রেমওয়ার্ক কোনো বড়‑শরীর আপনাকে চাপা দিয়ে দেয় না। এটাই কাস্টম আর্কিটেকচারকে বাস্তব করে তোলে: আপনি মিনিমাল থেকে শুরু করে প্রয়োজন অনুসারে ধাপে ধাপে টুকরা যোগ করতে পারবেন।
অধিকাংশ মাইক্রোফ্রেমওয়ার্ক‑ভিত্তিক অ্যাপ একটি রাউটার দিয়ে শুরু করে যা URL‑কে কন্ট্রোলার বা সরল হ্যান্ডলারের সাথে মিলায়। কন্ট্রোলারগুলো ফিচার (বিলিং, একাউন্ট) অথবা ইন্টারফেস (ওয়েব বনাম API) অনুযায়ী সংগঠিত করা যায়—আপনি কোড কিভাবে মেইনটেইন করতে চান তার ওপর নির্ভর করে।
মিডলওয়্যার সাধারণত রিকোয়েস্ট/রেসপন্স ফ্লোকে কভার করে এবং ক্রস‑কাটিং কনসার্নগুলোর জন্য সেরা স্থান:
মিডলওয়্যার কম্পোজেবল হওয়ায়, আপনি এটাকে গ্লোবালি প্রয়োগ করতে পারেন (সবকিছুতে লগিং লাগবে) অথবা নির্দিষ্ট রুটে (অ্যাডমিন এন্ডপয়েন্টে কড়া অথ) প্রয়োগ করতে পারেন।
মাইক্রোফ্রেমওয়ার্ক কমই কোনো ডেটা লেয়ার জোর করে দেয়, তাই আপনি এমনটি বেছে নিতে পারেন যা আপনার টিম ও ওয়র্কলোডের সঙ্গে মানায়:
একটি ভাল প্যাটার্ন হলো ডাটা অ্যাক্সেসকে রিপোজিটরি বা সার্ভিস লেয়ারের পেছনে রাখা, যাতে পরে টুল বদলালে হ্যান্ডলারগুলোতে ছড়িয়ে না পড়ে।
প্রোডাক্টে ডে‑ওয়ানে অ্যাসিঙ্ক প্রসেসিং লাগবে এমনটা নয়। প্রয়োজন হলে জব রানার ও কিউ যোগ করুন (ইমেইল, ভিডিও প্রসেসিং, ওয়েবহুক)। ব্যাকগ্রাউন্ড জবকে আলাদা “এনট্রি পয়েন্ট” হিসেবে বিবেচনা করুন—HTTP লেয়ারের সাথে একই সার্ভিস শেয়ার করুক, নিয়মগুলো ডুপ্লিকেট না বরং পুনঃব্যবহার্য হয়।
মিডলওয়্যারই মাইক্রোফ্রেমওয়ার্কগুলোর সবচেয়ে বড় সুবিধা দেয়: এটি আপনাকে ক্রস‑কাটিং প্রয়োজনগুলো—যা প্রতিটি রিকোয়েস্টে লাগবে—এক জায়গায় হ্যান্ডেল করতে দেয়, প্রতিটি রুট হ্যান্ডলারকে ফুল না করে। লক্ষ্য সহজ: হ্যান্ডলারগুলোকে ব্যবসায়িক লজিকে ফোকাস রাখতে দিন, ও মিডলওয়্যার প্লাম্বিং দিকগুলোর যত্ন নিক।
প্রতিটি এন্ডপয়েন্টে একই চেক ও হেডার বারবার করার বদলে একবার মিডলওয়্যারে যোগ করুন। একটি পরিষ্কার হ্যান্ডলার দেখতে পারে: ইনপুট পার্স করুন, সার্ভিস কল করুন, রেসপন্স ফেরত দিন। পরিবারের কাজগুলো—অথ, লগিং, ভ্যালিডেশন ডিফল্ট, রেসপন্স ফরম্যাটিং—আগে বা পরে হয়ে যেতে পারে।
অর্ডারই আচরণ নির্ধারণ করে। একটি সাধারণ, রিডেবল সিরিজ:
যদি কমপ্রেশন খুব আগেই চলে, এটি ত্রুটিগুলো ধরা বাদ দিতে পারে; আর যদি এরর হ্যান্ডলিং পরে চলে, তাহলে স্ট্যাক ট্রেস লিক বা inconsistent ফরম্যাটের রেসপন্স হতে পারে।
X-Request-Id হেডার যোগ করুন এবং লগে Include করুন।{ error, message, requestId })।মিডলওয়্যারকে উদ্দেশ্য অনুযায়ী গ্রুপ করুন (অবজার্ভেবিলিটি, সিকিউরিটি, পার্সিং, রেসপন্স শেইপিং) এবং সঠিক স্কোপে প্রয়োগ করুন: সত্যিই ইউনিভার্সাল রুলের জন্য গ্লোবাল, এবং নির্দিষ্ট এরিয়ার জন্য রুট‑গ্রুপ মিডলওয়্যার (যেমন /admin)। প্রতিটি মিডলওয়্যারকে স্পষ্টভাবে নাম দিন এবং সেটআপের কাছাকাছি ছোট একটি মন্তব্যে প্রত্যাশিত অর্ডার ডকুমেন্ট করুন যাতে ভবিষ্যতে পরিবর্তন গোপনে বিঘ্ন না ঘটায়।
মাইক্রোফ্রেমওয়ার্ক আপনাকে একটি পাতলা “রিকোয়েস্ট ইন, রেসপন্স আউট” কোর দেয়। বাকি সব—ডাটাবেস, ক্যাশ, ইমেইল, তৃতীয়‑পক্ষ API—টাকা‑বদলযোগ্য থাকা উচিৎ। এটাই যেখানে IoC ও DI সাহায্য করে, বড়‑কঠিন DI কন্টেইনার ছাড়াই।
যদি কোনো ফিচার ডাটাবেস চায়, সেখানে সরাসরি ডাটাবেস ক্লায়েন্ট তৈরি করা tempting ("new database client here")। এর অসুবিধা—প্রত্যেক জায়গা যা নিজে শপিং করে, সেটি সেই নির্দিষ্ট ক্লায়েন্টের সাথে কঠোরভাবে জড়িত হয়ে যায়।
IoC এ এটি উল্টে: আপনার ফিচার যা দরকার বলে বলবে, এবং অ্যাপের ওয়্যারিং ওইটা তাকে দিবে। আপনার ফিচার সহজে পুনঃব্যবহারযোগ্য ও বদলাতে সুবিধাজনক হয়।
ডিপেন্ডেন্সি ইনজেকশন মানে হলো নির্ভরশীলতা পাস করে দেয়া, ভিতরে তৈরি না করা। একটি মাইক্রোফ্রেমওয়ার্ক সেটআপে এটি প্রায়শই স্টার্টআপে করা হয়:
বড় DI কন্টেইনার ছাড়াও এভাবেই বেশি উপকার পাওয়া যায়। সহজ নিয়ম: এক জায়গায় ডিপেন্ডেন্সি কনস্ট্রাক্ট করুন এবং নিচে পাস করুন।
কম্পোনেন্টগুলোকে বদলযোগ্য রাখতে “আপনি যা চান” একটু ছোট ইন্টারফেসে সংজ্ঞায়িত করুন, তারপর কনক্রিট অ্যাডাপ্টার লিখুন।
প্যাটার্নের উদাহরণ:
UserRepository (ইন্টারফেস): findById, create, listPostgresUserRepository (অ্যাডাপ্টার): Postgres দিয়ে এগুলো ইমপ্লিমেন্ট করেInMemoryUserRepository (অ্যাডাপ্টার): টেস্টের জন্য একই মেথড ইমপ্লিমেন্ট করেআপনার বিজনেস লজিক কেবল UserRepository জানে, Postgres নয়। স্টোরেজ পরিবর্তন কনফিগারেশন‑চয়েস হয়ে ওঠে, রিরাইট নয়।
একই ধারণা বাইরের API‑র ক্ষেত্রেও কাজ করে:
PaymentsGateway ইন্টারফেসStripePaymentsGateway অ্যাডাপ্টারFakePaymentsGateway লোকাল ডেভেমাইক্রোফ্রেমওয়ার্কে কনফিগ ছড়িয়ে পড়া সহজ। এ থেকে বিরত থাকুন। একটি টেকসই প্যাটার্ন:
এতে আপনি মূল লক্ষ্য পাবেন: কোম্পোনেন্ট বদলানো অ্যাপ রিরাইট না করে সহজ কাজ। ডাটাবেস পরিবর্তন, API ক্লায়েন্ট প্রতিস্থাপন, বা কিউ যোগ করা হয়ে ওঠে কেবল ওয়্যারিং‑লেয়ারে ছোট পরিবর্তন—বাকি কোড স্থিতিশীল থাকে।
মাইক্রোফ্রেমওয়ার্কগুলো আপনাকে একটি “একটাই সঠিক পথ” চাপায় না। বদলে, রাউটিং, রিকোয়েস্ট/রেসপন্স হ্যান্ডলিং, এবং কিছু এক্সটেনশন পয়েন্ট দিয়ে এমন প্যাটার্নগুলো গ্রহণ করতে দেয় যা আপনার টিমের আকার, প্রোডাক্ট ম্যাচিউরিটি, এবং পরিবর্তনের হার অনুযায়ী মানায়।
এটি পরিচিত এবং সরল: কন্ট্রোলার HTTP বিষয়ে কাজ করে, সার্ভিস ব্যবসায়িক নিয়ম রাখে, এবং রিপোজিটরি ডাটাবেসে কথা বলে। ছোট‑মাঝারি টিমে, সরল ডোমেইনে এটি ভাল ফিট করে। মাইক্রোফ্রেমওয়ার্কে রাউটগুলো কন্ট্রোলারে ম্যাপ হয়, কন্ট্রোলার সার্ভিস কল করে, এবং রিপোজিটরি হালকা ম্যানুয়াল কম্পোজিশন দ্বারা ওয়্যার্ড করা হয়।
যখন আপনি আশা করেন সিস্টেম আজকের পছন্দগুলোকে অতিক্রম করবে (ডাটাবেস, মেসেজ বাস, তৃতীয়‑পক্ষ API, UI), তখন হেক্সাগোনাল আর্কিটেকচার দরকার হয়। মাইক্রোফ্রেমওয়ার্কগুলো এই ক্ষেত্রে ভালো কাজ করে কারণ ‘অ্যাডাপ্টার’ লেয়ার প্রায়ই HTTP হ্যান্ডলার এবং ডোমেইন কমান্ডে একটি পাতলা অনুবাদ ধাপে পরিণত হয়। ফ্রেমওয়ার্কটি এজে থাকে, কেন্দ্রে নয়।
অপারেশনাল ওভারহেড ছাড়াই মাইক্রোসার্ভিস‑মত স্পষ্টতা চাইলে মডুলার মনোলিথ শক্তিশালী অপশন। একটি ডিপ্লয়েবল অ্যাপ রাখা হয়, তবে ফিচার মডিউলে (Billing, Accounts, Notifications) ভাগ করা হয় এবং প্রতিটি মডিউলের পাবলিক API স্পষ্ট করা হয়।
মাইক্রোফ্রেমওয়ার্কগুলো এটি সহজ করে কারণ তারা অটো‑ওয়্যার করে না: প্রতিটি মডিউল নিজে রুট, ডিপেন্ডেন্সি, ও ডাটা অ্যাক্সেস রেজিস্টার করতে পারে, ফলে বাউন্ডারি দৃশ্যমান ও দুর্ঘটনাক্রমে লঙ্ঘন করা কঠিন হয়।
উপরে তিনটি প্যাটার্নে সুবিধা একই: আপনি নিয়ম বেছে নেন—ফোল্ডার লেআউট, ডিপেন্ডেন্সি দিক, ও মডিউল বাউন্ডারি—এবং মাইক্রোফ্রেমওয়ার্ক একটি ছোট, স্থির সারফেস প্রদান করে যাতে প্লাগ ইন করা যায়।
মাইক্রোফ্রেমওয়ার্ক আপনাকে ছোট করে শুরু করে নমনীয় থাকতে সাহায্য করে, কিন্তু বড় প্রশ্নটি থাকে: আপনার সিস্টেমের “আকার” কী হবে? সঠিক সিদ্ধান্ত প্রযুক্তিগত চেয়েও বেশি নির্ভর করে টিম সাইজ, রিলিজ কন্টেক্ট, এবং সমন্বয়ে কষ্ট কতটা হচ্ছে তার ওপর।
একটি মনোলিথ এক ডিপ্লয়েবল ইউনিট হিসেবে শিপ হয়। এটি সাধারণত দ্রুত প্রটোটাইপ বা প্রোডাক্ট পর্যন্ত যাওয়া সহজ পথ: এক বিল্ড, এক লগ সেট, এক জায়গায় ডিবাগ।
একটি মডুলার মনোলিথ এখনও এক ডিপ্লয়েবল, কিন্তু অভ্যন্তরে স্পষ্টভাবে মডিউল দ্বারা বিভক্ত। কোডবেস বড় হলে এটি প্রায়ই সেরা “পরবর্তী ধাপ” হয়—বিশেষত মাইক্রোফ্রেমওয়ার্কগুলোতে, যেখানে আপনি মডিউলগুলো স্পষ্ট রাখতে পারেন।
মাইক্রোসার্ভিস ডিপ্লয়েবলগুলোকে একাধিক সার্ভিসে ভাগ করে। এটি টিমগুলোর মধ্যে কাপলিং কমাতে পারে, কিন্তু অপারেশনাল কাজ গুনগুনায় বাড়ায়।
বিভক্ত করুন যখন একটি বাউন্ডারি ইতিমধ্যে আপনার কাজের মধ্যে বাস্তব:
এড়িয়ে চলুন যখন সেটা কেবল সুবিধার কারণ ("এই ফোল্ডার বড়") অথবা যখন সার্ভিসগুলো একই ডাটাবেস টেবিল শেয়ার করবে। এ ধরনের বিভাজন মানে আপনি স্থিতিশীল বাউন্ডারি ঠিক করেননি।
একটি API গেটওয়ে ক্লায়েন্টদের সহজ করে (এক এন্ট্রি পয়েন্ট, কেন্দ্রীভূত অথ/রেট‑লিমিটিং)। কিন্তু অসুবিধা: এটি যদি বেশি স্মার্ট হয়ে যায় তবে বটিলেক বা সিঙ্গেল ফেইলিওর পয়েন্ট হয়ে উঠতে পারে।
শেয়ার্ড লাইব্রেরি ডেভেলপমেন্টকে দ্রুত করে (কমন ভ্যালিডেশন, লগিং, SDKs), তবে এগুলো গোপন কাপলিং তৈরি করে। যদি একাধিক সার্ভিস একসাথে আপগ্রেড করতে হয়, তাহলে আপনি একটি ডিস্ট্রিবিউটেড মনোলিথ পুনর্নির্মাণ করছেন।
মাইক্রোসার্ভিসগুলো চলমান খরচ বাড়ায়: বেশি ডিপ্লয় পাইপলাইন, ভার্সনিং, সার্ভিস ডিসকভারি, মনিটরিং, ট্রেসিং, ইনসিডেন্ট রেসপন্স, ও অন‑কল রোটেশন। যদি আপনার টিম সেই মেশিনারি আরামদায়কভাবে চালাতে না পারে, তাহলে মাইক্রোফ্রেমওয়ার্ক উপাদান দিয়ে গঠিত একটি মডুলার মনোলিথ সাধারণত নিরাপদ বিকল্প।
মাইক্রোফ্রেমওয়ার্ক আপনাকে স্বাধীনতা দেয়, কিন্তু রক্ষণশীলতা ডিজাইন করতে হয়। লক্ষ্য হলো “কাস্টম” অংশগুলো খুঁজে পাওয়া সহজ, প্রতিস্থাপন করা সহজ, এবং ভুলভাবে ব্যবহার করা কঠিন করা।
একটি স্ট্রাকচার বেছে নিন যা আপনি এক মিনিটে ব্যাখ্যা করতে পারেন এবং কোড রিভিউ দিয়ে বজায় রাখুন। একটি ব্যবহারিক বিভাজন:
app/ (কম্পোজিশন রুট: মডিউলগুলোকে ওয়্যার করে)modules/ (বিজনেস সক্ষমতা)transport/ (HTTP রাউটিং, রিকোয়েস্ট/রেসপন্স ম্যাপিং)shared/ (কর্স‑কাটিং ইউটিলিটি: কনফিগ, লগিং, এরর টাইপ)tests/নামকরণ নিয়ম রক্ষা করুন: মডিউল ফোল্ডারগুলো নাউন (যেমন billing, users) ব্যবহার করুক, এবং এন্ট্রি পয়েন্টগুলো predictable (যেমন index, routes, service) হয়।
প্রতিটি মডিউলকে একটি ছোট প্রোডাক্ট হিসেবে বিবেচনা করুন:
modules/users/public.ts)modules/users/internal/*)“রিচ‑থ্রু” ইমপোর্ট এড়ান যেমন modules/orders/internal/db.ts অন্য কোন মডিউল থেকে। যদি অন্য অংশে দরকার হয়, তবে সেটা পবলিক API‑তে তুলুন।
ক্ষুদ্র সার্ভিসেরও মৌলিক দৃশ্যমানতা প্রয়োজন:
এগুলো shared/observability‑তে রাখুন যাতে প্রতিটি রুট হ্যান্ডলার একই কনভেনশন ব্যবহার করে।
ক্লায়েন্টের জন্য এরর‑গুলো পূর্বানুমেয় এবং মানুষের জন্য ডিবাগ করা সহজ করুন। একটি একক এরর শেইপ সংজ্ঞায়িত করুন (যেমন code, message, details, requestId) এবং প্রতিটি এন্ডপয়েন্টের জন্য এক ভ্যালিডেশন পদ্ধতি নির্ধারণ করুন। অভ্যন্তরীণ এক্সসেপশন থেকে HTTP রেসপন্সে ম্যাপিং কেন্দ্রীয়ভাবে রাখুন যাতে হ্যান্ডলার biznes logic‑এ ফোকাস রাখতে পারে।
আপনি দ্রুত যেতে চান কিন্তু মাইক্রোফ্রেমওয়ার্ক‑স্টাইল আর্কিটেকচার স্পষ্ট রাখতে চান—তাতে Koder.ai একটি সহায়ক টুল হিসেবে কাজে লাগতে পারে: এটি স্ক্যাফল্ডিং এবং ইটারেশন টুল হিসেবে, ভাল ডিজাইনের পরিবর্তে না। আপনি আপনার মডিউল বাউন্ডারি, মিডলওয়্যার স্ট্যাক, এবং এরর ফরম্যাট চ্যাটে বর্ণনা করে একটি কাজ করা বেসলাইন অ্যাপ জেনারেট করতে পারেন (উদাহরণস্বরূপ, React ফ্রন্টএন্ড + Go + PostgreSQL ব্যাকএন্ড) এবং তারপর ওয়্যারিং ধীরে ধীরে পরিশোধন করবেন।
দুইটি ফিচার বিশেষভাবে কাস্টম আর্কিটেকচার কাজে আসে:
Koder.ai সোর্স কোড এক্সপোর্ট সমর্থন করে, তাই আপনি আর্কিটেকচারের মালিকানা রাখেন এবং নিজের রিপোতে হাত চালিয়ে এটিকে সাধারণভাবে বিবর্তিত করতে পারবেন।
মাইক্রোফ্রেমওয়ার্ক‑ভিত্তিক সিস্টেমগুলো “হাত‑চালিত” মনে হতে পারে, যার ফলে টেস্টিং একটি নির্দিষ্ট ফ্রেমওয়ার্কের নিয়মের চেয়েও আপনার টুকরোগুলোর সিলগুলো রক্ষা করার ব্যাপার হয়ে ওঠে। লক্ষ্য হলো আত্মবিশ্বাস অর্জন করা, পুরো পরিবর্তনকে প্রতিটি পরিবর্তনের জন্য একটি সম্পূর্ণ end‑to‑end চালাতে বাধ্য না করে।
বিজনেস রুলগুলোর জন্য দ্রুত ইউনিট টেস্ট দিয়েই শুরু করুন (ভ্যালিডেশন, প্রাইসিং, পারমিশন লজিক)—কারণ এগুলো দ্রুত এবং ব্যর্থতার অবস্থান নির্দিষ্ট করে।
তারপর উচ্চ‑মানের কিছু ইন্টিগ্রেশন টেস্টে বিনিয়োগ করুন যা ওয়্যারিং পরীক্ষা করে: রাউটিং → মিডলওয়্যার → হ্যান্ডলার → পারসিস্টেন্স বাউন্ডারি। এগুলো টুকরা মিলিত হওয়ার সময় ঘটে এমন সূক্ষ্ম বাগ ধরবে।
মিডলওয়্যারেই ক্রস‑কাটিং আচরণ লুকায় (অথ, লগিং, রেট‑লিমিট)। এটাকে পাইপলাইনের মতো টেস্ট করুন:
হ্যান্ডলারগুলোর জন্য, সাধারণত পাবলিক HTTP শেইপ (স্ট্যাটাস কোড, হেডার, রেসপন্স বডি) টেস্ট করুন, অভ্যন্তরীণ ফাংশন কল না—এভাবে টেস্টগুলো ভিতরের পরিবর্তনেও স্থিতিশীল থাকে।
ডিপেন্ডেন্সি ইনজেকশন (বা কনস্ট্রাক্টর প্যারামিটার) ব্যবহার করে বাস্তব নির্ভরশীলতাগুলো ফেক দিয়ে বদলান:
যখন একাধিক সার্ভিস বা টিম একটি API‑র উপর নির্ভর করে, কন্ট্র্যাক্ট টেস্ট যোগ করুন যা রিকোয়েস্ট/রেসপন্স প্রত্যাশা লক করে রাখে। প্রোভাইডার‑পক্ষীয় কন্ট্র্যাক্ট টেস্ট নিশ্চিত করবে যে আপনি কনজিউমারদের অবাঞ্ছিতভাবে ব্রেক করছেন না, এমনকি আপনার মাইক্রোফ্রেমওয়ার্ক সেটআপ বা অভ্যন্তরীণ মডিউল বদলে গেলেও।
মাইক্রোফ্রেমওয়ার্কগুলো স্বাধীনতা দেয়, কিন্তু স্বাধীনতা স্বয়ংক্রিয়ভাবে স্পষ্টতা আনে না। প্রধান ঝুঁকিগুলো পরে দেখা দেয়—যখন টিম বাড়ে, কোডবেস বিস্তার লাভ করে এবং "অস্থায়ী" সিদ্ধান্তগুলো স্থায়ী হয়ে পড়ে।
কম বিল্ট‑ইন কনভেনশন থাকার ফলে দুই টিম একই ফিচার দুই ভিন্ন স্টাইলে (রাউটিং, এরর হ্যান্ডলিং, রেসপন্স ফরম্যাট, লগিং) বাস্তবায়ন করতে পারে। এসব অনিয়ম রিভিউ ধীর করে এবং অনবোর্ডিং কঠিন করে তোলে।
সহজ গার্ডরেইল: একটি ছোট “সার্ভিস টেমপ্লেট” ডক লিখুন (প্রজেক্ট স্ট্রাকচার, নামকরণ, এরর ফরম্যাট, লগিং ফিল্ড) এবং একটি স্টার্টার রিপো ও কিছু লিন্ট দিয়ে প্রয়োগ করুন।
প্রথমে পরিষ্কার শুরু হলেও, পরে utils/ ফোল্ডারটি হঠাৎ একটি দ্বিতীয় ফ্রেমওয়ার্কে পরিণত হতে পারে। যখন মডিউলগুলো হেল্পার, কনস্ট্যান্ট, এবং গ্লোবাল স্টেট শেয়ার করে, তখন বাউন্ডারি ব্লার হয় এবং পরিবর্তন চমকপ্রদ ভাঙ্গন তৈরি করে।
স্পষ্ট শেয়ার্ড প্যাকেজ পছন্দ করুন যেগুলো ভার্সনিং সাপোর্ট করে, অথবা শেয়ারিংকে সীমিত রাখুন: টাইপ, ইন্টারফেস, ও ভাল‑টেস্ট করা প্রিমিটিভ। যদি কোনো হেল্পার বিজনেস নিয়মের উপর নির্ভর করে, তাহলে সেটি utils‑এ নয় বরং ডোমেইন মডিউলে থাকা উচিত।
আপনি যখন নিজের হাতেই অথ, অথরাইজেশন, ইনপুট ভ্যালিডেশন, ও রেট‑লিমিটিং ওয়্যার করেন, তখন একটি রুট মিস করা, মিডলওয়্যার ভুলভাবে রেজিস্টার করা, বা শুধুই “হ্যাপি‑পাথ” ইনপুট ভ্যালিডেট করা সহজ হয়ে পড়ে।
সিকিউরিটি ডিফল্টস কেন্দ্রীয় করুন: সিকিউর হেডার, কনসিস্টেন্ট অথ চেক, এবং এজে ভ্যালিডেশন। এছাড়া টেস্ট যোগ করুন যাতে প্রোটেকটেড এন্ডপয়েন্টগুলো প্রকৃতেই প্রোটেকটেড আছে।
অজানতে অনেকগুলো মিডলওয়্যার একসাথে লাগানোর ফলে ওভারহেড বাড়ে—বিশেষত যদি একাধিক মিডলওয়্যার বডি পার্স করে, স্টোরেজ অ্যাক্সেস করে, বা লগ সিরিয়ালাইজ করে।
মিডলওয়্যারগুলোকে ছোট ও মেজারেবল রাখুন। স্ট্যান্ডার্ড অর্ডার ডকুমেন্ট করুন এবং নতুন মিডলওয়্যার যোগ করার সময় খরচ মূল্যায়ন করুন। যদি বাতিক্রম দেখা যায়, রিকোয়েস্ট প্রোফাইল করে অপ্রয়োজনীয় ধাপ সরান।
মাইক্রোফ্রেমওয়ার্কগুলো আপনাকে বিকল্প দেয়—কিন্তু বিকল্পগুলো একটি সিদ্ধান্ত প্রক্রিয়া চায়। লক্ষ্যটি “সেরা” আর্কিটেকচার খোঁজা নয়; বরং এমন একটি আকৃতি বেছে নেওয়া যা আপনার টিম আরাম করে বানাতে, অপারেট করতে, এবং পরিবর্তন করতে পারে।
মনোলিথ বা মাইক্রোসার্ভিস বেছে নেওয়ার আগে উত্তর দিন:
অনিশ্চিত হলে, মাইক্রোফ্রেমওয়ার্ক ব্যবহার করে মডুলার মনোলিথ‑এর দিকে ডিফল্ট করুন। এটি বাউন্ডারি স্পষ্ট রাখে এবং শিপ সহজ করে।
মাইক্রোফ্রেমওয়ার্ক আপনাকে কনসিস্টেন্সি চাপাবে না, তাই আগে থেকে কনভেনশন ঠিক করুন:
/docs‑এ একটি এক‑পেজ সার্ভিস কনট্রাক্ট যথেষ্ট হতে পারে।
প্রারম্ভে যে ক্রস‑কাটিং অংশগুলো প্রতিটি জায়গায় লাগবে সেগুলো ঠিক করুন:
এসবকে শেয়ার্ড মডিউল হিসেবে বিবেচনা করুন, কপি‑পেস্ট করে নয়।
আর্কিটেকচার সময়ের সাথে বদলানো উচিত। প্রতি কোয়ার্টারে পর্যালোচনা করুন কোথায় ডিপ্লয় ধীর হচ্ছে, কোন অংশ আলাদাভাবে স্কেল করছে, এবং কোন জিনিস সবচেয়ে বেশি ব্রেক করছে। যদি একটি ডোমেইন বাধা হয়ে দাঁড়ায়, সেটাই আপনার পরবর্তী স্প্লিটের প্রার্থী—না পুরো সিস্টেম।
একটি মাইক্রোফ্রেমওয়ার্ক সেটআপ সাধারণত পুরোপুরি ডিজাইনকৃত শুরু করে না। এটি সাধারণত একটি API দিয়ে শুরু করে, একটি টিম এবং একটি টাইট ডেডলাইন নিয়ে। মূল্য তখন প্রকাশ পায় যখন প্রোডাক্ট বৃদ্ধি পায়: নতুন ফিচার আসে, আরও মানুষ কোডে কাজ করে, এবং আপনার আর্কিটেকচারকে টানতে হয় কিন্তু ভাঙতে দেয়া যাবে না।
আপনি একটি মিনিমাল সার্ভিস দিয়ে শুরু করবেন: রাউটিং, রিকোয়েস্ট পার্সিং, এবং এক ডাটাবেস অ্যাডাপ্টার। বেশিরভাগ লজিক এন্ডপয়েন্টের কাছে থাকে কারণ দ্রুত শিপ করা সুবিধাজনক।
যখন আপনি অথ, পেমেন্ট, নোটিফিকেশন, রিপোর্টিং যোগ করবেন, তখন সেগুলোকে মডিউলে বিভক্ত করবেন (ফোল্ডার বা প্যাকেজ) যাতে প্রতিটি মডিউল নিজে মালিকানা, মডেল, ও ডাটা অ্যাক্সেস রাখে এবং কেবল যা অন্যদের দরকার তা প্রকাশ করে।
লগিং, অথ চেক, রেট‑লিমিটিং, এবং রিকোয়েস্ট ভ্যালিডেশন মিডলওয়ারে চলে আসে যাতে প্রতিটি এন্ডপয়েন্ট ধারাবাহিকভাবে আচরণ করে। যেহেতু অর্ডার গুরুত্বপূর্ণ, তাই এটি ডকুমেন্ট করা উচিত।
ডকুমেন্ট করুন:
রিফ্যাক্টর করুন যখন মডিউলগুলো খুব বেশি ইন্টারনাল শেয়ার করে, বিল্ড টাইম উল্লেখযোগ্যভাবে ধীর হয়, বা ছোট পরিবর্তনগুলো একাধিক মডিউলে এডিট করাকে বাধ্যতর করে।
সার্ভিস আলাদা করার কথা ভাবুন যখন টিমগুলো শেয়ারড ডিপ্লয়মেন্টে আটকে, বিভিন্ন অংশ আলাদা ভাবে স্কেল করতে হবে, অথবা একটি ইন্টিগ্রেশন বাউন্ডারি ইতিমধ্যে আলাদা প্রোডাক্টের মতো আচরণ করছে।
মাইক্রোফ্রেমওয়ার্কগুলো সেইসব ক্ষেত্রে ভালো হয় যেখানে আপনি স্ট্যাকের বদলে আপনার ডোমেইন অনুযায়ী অ্যাপটি গঠন করতে চান। এগুলো বিশেষত তাদের জন্য কার্যকর যারা স্বচ্ছতা পছন্দ করে: আপনি কিছু মূল বিল্ডিং ব্লক বেছে নেবেন এবং সেগুলো বজায় রাখার বিনিময়ে একটি কোডবেস পাবেন যা পরিবর্তনের সাথে বোঝাপড়া বজায় রাখতে পারে।
আপনার নমনীয়তা তখনই ফল দেবে যখন আপনি কিছু অভ্যাস রাখবেন:
দুইটি হালকা‑ওজন আর্টিফ্যাক্ট দিয়ে শুরু করুন:
সবশেষে, প্রতিটি সিদ্ধান্ত ডকুমেন্ট করুন—ছোট নোটও সাহায্য করে। আপনার রিপোতে একটি “Architecture Decisions” পৃষ্ঠা রাখুন এবং সেটি নিয়মিত পর্যালোচনা করুন যাতে গতকালকের শর্টকাট আজকের সীমাবদ্ধতায় পরিণত না হয়।
মাইক্রোফ্রেমওয়ার্কগুলো মূলত অপরিহার্য বিষয়গুলোয় মনোযোগ দেয়: রাউটিং, রিকোয়েস্ট/রেসপন্স হ্যান্ডলিং এবং বর্ধনযোগ্য পয়েন্ট।
ফুল‑স্ট্যাক ফ্রেমওয়ার্ক সাধারণত অনেক “ব্যাটারি ইনক্লুডেড” ফিচার (ORM, অথেনটিকেশন, অ্যাডমিন, ফর্ম, ব্যাকগ্রাউন্ড জব) দিয়ে আসে। মাইক্রোফ্রেমওয়ার্কগুলো সুবিধার বদলে নিয়ন্ত্রণ দেয়—আপনি শুধু যেগুলো প্রয়োজন, সেগুলোই যোগ করবেন এবং সিদ্ধান্ত নিবেন কোন কম্পোনেন্টগুলো কীভাবে সংযুক্ত হবে।
নিচু-ওজনের স্ট্যাক ছাড়া দ্রুত ডেলিভারি করতে হলে মাইক্রোফ্রেমওয়ার্ক ভালো বিকল্প:
একটি “ছোট্ট কার্যকর কোর” সাধারণত:
এগুলি দিয়ে একটি এন্ডপয়েন্ট শিপ করা যায়; তারপর প্রয়োজন দেখা দিলে মডিউল (auth, validation, observability, queues) যোগ করুন।
মিডলওয়্যার সাধারণত বিস্তৃত প্রাসঙ্গিক বিষয়গুলোর জন্য সবচেয়ে উপযোগী, উদাহরণ:
রুট হ্যান্ডলারগুলোকে ব্যবসায়িক লজিকে ফোকাস রাখতে হবে: parse → call service → return response।
অর্ডার ব্যবহারের আচরণ নির্ধারণ করে। একটি সাধারণ, বিশ্বস্ত সিকোয়েন্স:
সেটআপ কোডের কাছে অর্ডারটি ডকুমেন্ট করে রাখুন যাতে ভবিষ্যতে পরিবর্তনে আচরণ অজান্তে ভেঙে না যায়।
IoC মানে হলো আপনার বিজনেস কোড নিজেই তার নির্ভরশীলতা তৈরি করবে না (“শপিং করবে না”)—বরং অ্যাপের ওয়্যারিং যা প্রয়োজন তা সরবরাহ করবে।
ব্যবহারিকভাবে: স্টার্টআপে ডাটাবেস ক্লায়েন্ট, লগার, API ক্লায়েন্টগুলো তৈরি করুন এবং সেগুলো সার্ভিস/হ্যান্ডলারে পাস করুন। এতে টাইট কাপলিং কমে এবং টেস্টিং ও বদল করা সহজ হয়।
না। অধিকাংশ DI সুবিধা আপনি সহজ কম্পোজিশন রুট থেকেই পেতে পারেন:
যদি নির্ভরশীলতার গ্রাফ বড় হয়ে অগোছালো মনে হয়, তখন কন্টেইনার বিবেচনা করুন—কিন্তু ডিফল্ট হিসেবে জটিলতা যোগ করবেন না।
স্টোরেজ ও বাইরের API‑গুলিকে ছোট ইন্টারফেসের (পোর্ট) পিছনে রাখুন, তারপর নির্দিষ্ট অ্যাডাপ্টার লিখুন:
UserRepository ইন্টারফেস: findById, create, listPostgresUserRepository প্রোডাকশনেএকটি ব্যবহারিক স্ট্রাকচার যা বাউন্ডারি দৃশ্যমান রাখে:
app/ কম্পোজিশন রুট (ওয়্যারিং)modules/ ফিচার মডিউল (ডোমেইন ক্ষমতা)transport/ HTTP রাউটিং ও রিকোয়েস্ট/রেসপন্স ম্যাপিংshared/ কনফিগ, লগিং, এরর টাইপ, অবজার্ভেবিলিটিব্যবসায়িক নিয়মগুলোর জন্য দ্রুত ইউনিট টেস্ট প্রধান্য দিন, তারপর কিছু উচ্চ‑মানের ইন্টিগ্রেশন টেস্ট রাখুন যা পুরো পাইপলাইন (রাউটিং → মিডলওয়্যার → হ্যান্ডলার → পারসিস্টেন্স বাউন্ডারি) পরীক্ষা করে।
DI/fake ব্যবহার করে বাহ্যিক সার্ভিসগুলো আইসোলেট রাখুন, এবং মিডলওয়্যারকে পাইপলাইনের মতো টেস্ট করুন (হেডার, পার্শ্ব‑প্রভাব, ব্লকিং আচরণ যাচাই)। একাধিক টিম যখন API‑র উপর নির্ভর করে, তখন কন্ট্র্যাক্ট টেস্ট যোগ করুন যাতে ব্রেকিং চেঞ্জ এড়ানো যায়।
InMemoryUserRepository টেস্টেহ্যান্ডলার/সার্ভিসগুলো কনক্রিট টুল না দেখে ইন্টারফেসের সাথে কাজ করবে। ডাটাবেস বা পেমেন্ট প্রোভাইডার বদলানো হয়ে উঠবে কনফিগ/ওয়্যারিং পরিবর্তন, রিরাইট নয়।
tests/মডিউল পাবলিক API বজায় রাখুন (যেমন modules/users/public.ts) এবং অন্য মডিউলের ইনটারনাল‑এ সরাসরি রিচ‑থ্রু ইমপোর্ট এড়ান।