3.2 স্থাপত্য শৈলী ও প্যাটার্ন

পরিচিতি ও প্রেরণা

একটি স্থাপত্য শৈলী হলো একটি সিস্টেম সাজানোর বিস্তৃত, পুনর্ব্যবহারযোগ্য আকার: কীভাবে তা বিভক্ত, অংশগুলো কীভাবে যোগাযোগ করে এবং সীমানা কোথায় পড়ে। একটি বাছাই করা একটি বড় প্রতিষ্ঠানের সবচেয়ে গুরুত্বপূর্ণ (এবং সবচেয়ে ভুল-বোঝা) সিদ্ধান্তের একটি। প্রায়ই পছন্দ দলের, ডোমেইনের ও পরিচালনগত বাস্তবতার আসল সীমাবদ্ধতার বদলে ফ্যাশন অনুসরণ করে (“সবাই মাইক্রোসার্ভিস করছে”)। আপনি দুই ধরনের জট পান: একটি বিতরিত সিস্টেম যা প্রতিষ্ঠান চালাতে পারে না, অথবা একটি জট পাকানো মনোলিথ যা কেউ নিরাপদে বদলাতে পারে না। কোনোটি শৈলীর দোষ নয়। দুটিই শৈলীকে পরিস্থিতির সঙ্গে ভুলভাবে মেলানো থেকে আসে।

বড় ডেভেলপার দলের জন্য শৈলী সর্বোপরি কনওয়ের সূত্রের কারণে গুরুত্বপূর্ণ: একটি সিস্টেমের কাঠামো তাকে বানানো প্রতিষ্ঠানের যোগাযোগ কাঠামো প্রতিফলিত করে। তাই একটি স্থাপত্য শৈলী সাংগঠনিক নকশার সিদ্ধান্তও। একটি সিস্টেমকে সার্ভিসে ভাগ করা আসলে দল, মালিকানা ও অন-কল দায়িত্ব ভাগ করার সিদ্ধান্ত। শত শত ইঞ্জিনিয়ারের এন্টারপ্রাইজ স্বাধীন ডিপ্লয়মেন্টসহ সূক্ষ্ম-কণা সার্ভিসের সামর্থ্য রাখে (এবং প্রায়ই প্রয়োজন), কারণ সেই স্বাধীনতাই অনেক দলকে একে অন্যকে আটকে না রেখে পাঠাতে দেয়। একই প্যাটার্ন একটি একক ছোট দলের ওপর চাপান, সে সাংগঠনিক সুবিধা ছাড়াই সব পরিচালনগত কর উত্তরাধিকার পায়।

সরকারি ও এন্টারপ্রাইজ পরিবেশ আরও সীমাবদ্ধতা চাপায়: দীর্ঘ সিস্টেম জীবনকাল, কঠোর পরিবর্তন-নিয়ন্ত্রণ, ক্রয় চক্র, প্রোথিত রেকর্ড-সিস্টেমের সঙ্গে ইন্টিগ্রেশন এবং নিরীক্ষণযোগ্যতা। এগুলো এমন শৈলী পছন্দ করে যা সীমানা সুস্পষ্ট ও নির্ভরতা পরিদর্শনে সহজ রাখে। এই অধ্যায় প্রধান শৈলী জরিপ করে: মনোলিথ থেকে মাইক্রোসার্ভিস, CQRS ও ইভেন্ট সোর্সিংসহ ইভেন্ট-চালিত স্থাপত্য, সার্ভিস মেশ ও গেটওয়ে প্যাটার্ন, সার্ভারলেস, এবং হেক্সাগোনাল ও ক্লিন আর্কিটেকচারের অভ্যন্তরীণ শৃঙ্খলা। আরও জরুরি, এটি আপনাকে বলতে সাহায্য করে প্রতিটি কখন মানায়।

আরও দেখুন: অধ্যায় 2.2 (সফটওয়্যার নকশা নীতি, ডোমেইন-ড্রিভেন ডিজাইনসহ), অধ্যায় 3.1 (স্থাপত্যের মৌলিক বিষয়) এবং অধ্যায় 3.3 (বিতরিত সিস্টেম)।

মূল নীতিসমূহ

• শৈলী শক্তি অনুসরণ করে, ফ্যাশন নয়। দলের আকার, ডোমেইনের জটিলতা, লোড ও পরিচালনগত পরিপক্বতার ভিত্তিতে বাছুন, কোনো প্রযুক্তি জনপ্রিয় বলে কখনো নয়।
• আসল শত্রু সংযুক্তি, ডিপ্লয়যোগ্য ইউনিটের সংখ্যা নয়। একটি সুমডিউলারাইজড মনোলিথ বিতরিত বিগ বল অব মাডকে হারায়।
• বিতরণ হলো স্বাধীনতার জন্য আপনি যে খরচ দেন। কেবল তখনই ভাগ করুন যখন স্বাধীন ডিপ্লয়মেন্ট, স্কেলিং বা ব্যর্থতা-বিচ্ছিন্নতার মূল্য নেটওয়ার্ক কল, আংশিক ব্যর্থতা এবং সার্ভিস জুড়ে ডেটা সামঞ্জস্যের খরচ ছাড়ায়।
• সীমানা ব্যবসায়িক ডোমেইন অনুসরণ করা উচিত। সার্ভিস ও মডিউলকে বাউন্ডেড কনটেক্সটের (প্রতিটি নিজস্ব সুস্পষ্ট সীমানাসহ একটি স্বয়ংসম্পূর্ণ ডোমেইন মডেল) সঙ্গে সারিবদ্ধ করুন, প্রযুক্তিগত স্তরের সঙ্গে নয়।
• বাইরেরটা যা-ই হোক, ভেতরটা ভালো নকশা করুন। হেক্সাগোনাল/ক্লিন স্তরবিন্যাস প্রতিটি শৈলীতে ব্যবসায়িক যুক্তিকে ফ্রেমওয়ার্ক ও অবকাঠামো থেকে স্বাধীন রাখে।
• কনওয়ের সূত্র অনিবার্য, তাই তা কাজে লাগান। দলের সীমানা ও স্থাপত্য একসঙ্গে নকশা করুন।
• আপনি যতটা ভাবেন তার চেয়ে সরলভাবে শুরু করুন। একটি ভালো মডিউলার মনোলিথ থেকে সার্ভিস বের করা যায়; অকাল মাইক্রোসার্ভিস জট বিতরণ-মুক্ত করা অনেক কঠিন।

সুপারিশ

মডিউলার মনোলিথ দিয়ে শুরু করুন; প্রমাণ নিয়ে ভাগ করুন

বেশিরভাগ সিস্টেম একটি একক ডিপ্লয়যোগ্য ইউনিট হিসেবে শুরু করুন, শক্তিশালী অভ্যন্তরীণ মডিউল সীমানাসহ: স্পষ্ট ইন্টারফেস, অন্য মডিউলের ডেটায় হাত না বাড়ানো, এবং প্রয়োগ করা নির্ভরতা নিয়ম। আপনি সহজ লেনদেন, সহজ রিফ্যাক্টরিং, এবং ডিপ্লয় ও পর্যবেক্ষণের জন্য একটি জিনিস পান। একটি মডিউলকে নিজস্ব সার্ভিসে ভাগ করুন কেবল যখন সুনির্দিষ্ট কারণ আছে: একটি অংশ যা নিজে স্কেল করতে হবে, একটি দল যাকে নিজস্ব ছন্দে ডিপ্লয় করতে হবে, একটি ব্যর্থতা ডোমেইন যা বিচ্ছিন্ন করতে হবে, বা বাকিদের থেকে ভিন্ন প্রযুক্তি প্রয়োজন। ভাগ করলে বাউন্ডেড-কনটেক্সট রেখা ধরে ভাগ করুন যাতে প্রতিটি সার্ভিস নিজের ডেটার মালিক হয় এবং একটি স্থিতিশীল চুক্তি প্রকাশ করে।

জানুন মাইক্রোসার্ভিস কখন নিজের জায়গা অর্জন করে

মাইক্রোসার্ভিস আপনাকে স্বাধীন ডিপ্লয়যোগ্যতা, স্বাধীন স্কেলিং, ব্যর্থতা-বিচ্ছিন্নতা এবং প্রযুক্তি মেশানোর স্বাধীনতা দেয়। বিনিময়ে তারা দাবি করে পরিণত CI/CD (কন্টিনিউয়াস ইন্টিগ্রেশন ও কন্টিনিউয়াস ডেলিভারি), স্বয়ংক্রিয় অবকাঠামো, বিতরিত ট্রেসিং, সার্ভিস আবিষ্কার এবং একটি অন-কল সংস্কৃতি। নিজেকে সৎভাবে জিজ্ঞেস করুন: আপনার প্রতিষ্ঠান কি প্রোডাকশনে ডজন ডজন স্বাধীনভাবে ডিপ্লয় করা সার্ভিস নির্ভরযোগ্যভাবে চালাতে পারে? প্ল্যাটফর্ম ও পরিচালনগত পরিপক্বতা না থাকলে মাইক্রোসার্ভিস কেবল আপনার ব্যর্থতার ধরন গুণ করে, তাদের সুবিধা না দিয়ে। অনেক প্রতিষ্ঠান ক্ষুদ্র সার্ভিসের ঝাঁকের বদলে প্রধান ডোমেইনের সঙ্গে সারিবদ্ধ হাতে-গোনা মোটা-কণা সার্ভিস নিয়ে সবচেয়ে ভালো করে।

যেখানে বিযুক্তি ও অ্যাসিনক্রোনি ফল দেয় সেখানে ইভেন্ট-চালিত স্থাপত্য ব্যবহার করুন

ইভেন্ট-চালিত স্থাপত্য উৎপাদকদের কে ভোগ করে তা না জেনে তথ্য নির্গত করতে দেয়। এটি আপনাকে শিথিল সংযুক্তি, লোড স্পাইকের বাফার, এবং নতুন ভোক্তা যোগ করার সহজ উপায় কেনে। যেখানে কর্মপ্রবাহ স্বাভাবিকভাবে অ্যাসিনক্রোনাস ও প্রতিক্রিয়াশীল সেখানে এটি ব্যবহার করুন। CQRS (Command Query Responsibility Segregation) লেখার মডেলকে এক বা একাধিক পড়ার মডেল থেকে আলাদা করে, যা পড়া ও লেখার লোড বা আকার তীব্রভাবে ভিন্ন হলে সাহায্য করে। ইভেন্ট সোর্সিং বর্তমান অবস্থার বদলে অবস্থাকে ইভেন্টের কেবল-যোগ-করা লগ হিসেবে সংরক্ষণ করে, আপনাকে নিখুঁত নিরীক্ষা ট্রেইল ও সময়-ভ্রমণ দেয়। এটি অর্থ ও সরকারের জন্য শক্তিশালী, যেখানে “আমরা এই মানে কীভাবে পৌঁছালাম?” একটি আইনি প্রশ্ন, তবে ইভেন্ট সংস্করণ, প্রজেকশন পুনর্নির্মাণ এবং পরিণামী সামঞ্জস্য নিয়ে যুক্তিতে প্রকৃত জটিলতা যোগ করে। এগুলো ডিফল্টে নয়, ইচ্ছাকৃতভাবে ধরুন।

অনেক সার্ভিস সামলাতে গেটওয়ে, BFF ও মেশ প্যাটার্ন প্রয়োগ করুন

একটি API গেটওয়ে বাইরের ক্লায়েন্টদের একটি একক প্রবেশ বিন্দু দেয়, প্রমাণীকরণ, হার সীমাবদ্ধকরণ, রাউটিং এবং TLS (Transport Layer Security) টার্মিনেশন সামলে। একটি Backend-for-Frontend (BFF) প্রতিটি ক্লায়েন্ট ধরনকে (ওয়েব, মোবাইল, পার্টনার API) নিজস্ব উপযোগী সংযোজন স্তর দেয়, ফলে আপনি স্ফীত একমাপ-সবার-জন্য API এড়ান। একটি সার্ভিস মেশ ক্রস-কাটিং উদ্বেগ (পারস্পরিক TLS, রিট্রাই, টাইমআউট, ট্রাফিক স্থানান্তর ও টেলিমেট্রি) একটি সাইডকার অবকাঠামো স্তরে সরায়, যাতে অ্যাপ্লিকেশন দলগুলোকে সেগুলো পুনর্বাস্তবায়ন করতে না হয়। মেশ যোগ করুন কেবল যখন সার্ভিসের সংখ্যা এই উদ্বেগ প্রতি-সার্ভিসে সামলানো অসামলানোযোগ্য করে। অল্প সার্ভিসের জন্য মেশ মূল্যের চেয়ে বেশি পরিচালনগত ওজন।

সার্ভারলেস সৎভাবে ওজন করুন

ফাংশন-অ্যাজ-আ-সার্ভিস ও ম্যানেজড সার্ভারলেস প্ল্যাটফর্ম সার্ভার ব্যবস্থাপনা আপনার থালা থেকে সরায়, শূন্যে স্কেল করে এবং ব্যবহার অনুযায়ী বিল করে, যা স্পাইকি, ইভেন্ট-চালিত বা নিম্ন-ভিত্তিরেখা ওয়ার্কলোড ও ছোট দলের জন্য চমৎকার। বিনিময় প্রকৃত: কোল্ড-স্টার্ট লেটেন্সি, এক্সিকিউশন-সময় ও সম্পদ সীমা, কঠিনতর স্থানীয় টেস্টিং, সম্ভাব্য বিক্রেতা লক-ইন, এবং টেকসই উচ্চ ভলিউমে প্রভিশন করা অবকাঠামোকে ছাড়াতে পারা খরচ। যেখানে এর অর্থনীতি ও পরিচালনগত সরলতা স্পষ্টভাবে জেতে সেখানে সার্ভারলেস ব্যবহার করুন। উৎসাহবশত স্থির, উচ্চ-থ্রুপুট মূল সিস্টেমকে তাতে ঢোকাবেন না।

প্রতিটি সার্ভিসের ভেতরে ব্যবসায়িক যুক্তি পরিচ্ছন্ন রাখুন

বাইরের শৈলী যা-ই হোক, ভেতরটা পরিচ্ছন্ন রাখুন হেক্সাগোনাল (পোর্ট ও অ্যাডাপ্টার) বা ক্লিন আর্কিটেকচার দিয়ে: ব্যবসায়িক নিয়ম কেন্দ্রে, কেবল অ্যাবস্ট্র্যাকশনের ওপর নির্ভর করে; ফ্রেমওয়ার্ক, ডেটাবেস ও মেসেজিং প্রান্তে প্রতিস্থাপনযোগ্য অ্যাডাপ্টার হিসেবে। এটি আপনার মূল্যবান ডোমেইন যুক্তিকে অবকাঠামো ছাড়াই পরীক্ষাযোগ্য এবং প্রযুক্তি পরিবর্তন জুড়ে বহনযোগ্য রাখে: ফ্রেমওয়ার্কের কয়েক প্রজন্ম টিকে থাকা দীর্ঘজীবী সরকারি ও এন্টারপ্রাইজ সিস্টেমের জন্য একটি নির্ণায়ক সুবিধা।

ট্রেড-অফ: সুবিধা ও অসুবিধা

শৈলী	সবচেয়ে ভালো যখন	সুবিধা	অসুবিধা
মডিউলার মনোলিথ	বেশিরভাগ সিস্টেম, বিশেষত শুরুতে	সরল পরিচালনা, সহজ লেনদেন ও রিফ্যাক্টরিং	একক ডিপ্লয় ইউনিট; একটিমাত্র হিসেবে স্কেল করে; ক্ষয়ের ঝুঁকি
মাইক্রোসার্ভিস	অনেক দল, উচ্চ স্কেল, পরিণত প্ল্যাটফর্ম	স্বাধীন ডিপ্লয়/স্কেল, ব্যর্থতা-বিচ্ছিন্নতা	বিতরিত জটিলতা, ডেটা সামঞ্জস্য, উচ্চ পরিচালন খরচ
ইভেন্ট-চালিত / CQRS / ইভেন্ট সোর্সিং	অ্যাসিনক্রোনাস কর্মপ্রবাহ, নিরীক্ষা প্রয়োজন, ভিন্নমুখী পড়া/লেখা	শিথিল সংযুক্তি, নিরীক্ষণযোগ্যতা, স্কেলযোগ্য পড়া	পরিণামী সামঞ্জস্য, ইভেন্ট সংস্করণ, কঠিনতর ডিবাগিং
সার্ভারলেস	স্পাইকি বা নিম্ন-ভিত্তিরেখা, ইভেন্ট-চালিত কাজ	সার্ভার ব্যবস্থাপনা নেই, শূন্যে স্কেল, ব্যবহার-অনুযায়ী মূল্য	কোল্ড স্টার্ট, সীমা, লক-ইন, উচ্চ টেকসই লোডে খরচ

পুনরাবৃত্ত বিষয়: আপনি পরিচালনগত ও জ্ঞানীয় জটিলতার বিনিময়ে নমনীয়তা ও স্বাধীনতা কেনেন। বিতরিত ও ইভেন্ট-চালিত শৈলী স্বাধীনভাবে স্কেল, ডিপ্লয় ও ব্যর্থ হওয়ার সামর্থ্যের বিনিময়ে একটি কল স্ট্যাক ও একটি লেনদেনের সরলতা ছেড়ে দেয়। এই বিনিময় স্কেলে ও পরিণত প্ল্যাটফর্মসহ ফল দেয়। তা ছাড়া এটি সর্বনাশা। অভ্যন্তরীণ শৃঙ্খলা (হেক্সাগোনাল/ক্লিন) প্রায় সবসময় সার্থক, কারণ তারা কম খরচ করে এবং পরে শৈলী বদলানোর বিকল্প খোলা রাখে।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. পরবর্তী সার্ভিস ভাগ করার আগে, যে দল তার মালিক হবে তাকেও কি ভাগ করবেন, এবং সেই কর্তৃত্ব কার? কনওয়ের সূত্রের মানে একটি সার্ভিস সীমানা আসলে একটি দলের সীমানা, তাই যে ভাগকে সংগঠন-চিত্র সমর্থন করে না তা একটি বিতরিত মনোলিথ তৈরি করে: দুটি ডিপ্লয়যোগ্য, একটি রিলিজ ট্রেন, ভাগ করা অন-কল। একটি বড় এন্টারপ্রাইজে দল পুনর্গঠনের কর্তৃত্ব সাধারণত প্রকৌশলের ওপরে বসে, রিপোর্টিং লাইন, অর্থ ও HR-এর কাছে, তাই স্থাপত্য ও সংগঠন নকশা একসঙ্গে ঠিক করতে হয়। আলোচনায় প্রমাণ আনুন: প্রস্তাবিত সার্ভিসের কি এমন একটি দল আছে যা শুরু থেকে শেষ পর্যন্ত এর মালিক হতে, নিজস্ব অন-কল চালাতে এবং নিজস্ব ছন্দে ডিপ্লয় করতে পারে? উত্তর না হলে হয় দলটিকে অর্থায়ন করুন নয়তো সামর্থ্যকে মনোলিথের একটি মডিউল রাখুন। মালিকানা ভাগ না করে কোড ভাগ করা বিতরণের প্রতিটি খরচ কেনে এবং স্বাধীনতার কোনোটিই নয়।

2. আজ কি আপনি প্রতিটি সার্ভিস স্বাধীনভাবে ডিপ্লয় করতে পারেন, নাকি তারা গোপনে একসঙ্গে পাঠায়? বিতরিত মনোলিথ এই অধ্যায়ের সবচেয়ে খারাপ ফল: আপনি নেটওয়ার্ক কল, আংশিক ব্যর্থতা ও সার্ভিস জুড়ে ডেটা সামঞ্জস্যের দাম দেন, তবু অন্যগুলো ছাড়া একটি রিলিজ করতে পারেন না। লক্ষণ হলো একটি ভাগ করা ডেটাবেস, একটি ভাগ করা লাইব্রেরি যা সমন্বিত আপগ্রেড বাধ্য করে, এবং সমস্ত সম্পত্তি একসঙ্গে চালাতে হওয়া ইন্টিগ্রেশন টেস্ট। একটি বড় দলের জন্য এটি নিঃশব্দে থ্রুপুট সীমিত করে, কারণ চিত্র স্বাধীনতা দেখালেও প্রতিটি দল একটি রিলিজের পেছনে সারিতে দাঁড়ায়। একটি সাম্প্রতিক পরিবর্তন নিন এবং গুনুন নিরাপদ করতে কতগুলো সার্ভিস একসঙ্গে ডিপ্লয় করতে হয়েছিল; একটি একক সামর্থ্য ছোঁয়া পরিবর্তনের জন্য সংখ্যা একের বেশি হলে আপনার সীমানা ভুল। সমাধান সাধারণত প্রতিটি সার্ভিসকে নিজস্ব ডেটা ও একটি স্থিতিশীল, সংস্করণযুক্ত চুক্তি দেওয়া, আরও সার্ভিস যোগ করা নয়।

3. আপনার বিদ্যমান সার্ভিস ভাগের কোনগুলো ফল দেওয়া বন্ধ করেছে, এবং আপনি কি সেগুলো আবার একত্র করবেন? অধ্যায়ের সবচেয়ে উন্নত অভ্যাস হলো শৈলী সিদ্ধান্তকে ফেরানো-যায় গণ্য করা: চালক দেখা দিলে বের করুন, চালক উধাও হলে আবার মেলান। বেশিরভাগ প্রতিষ্ঠান কেবল ভাগই করে, তাই ন্যানোসার্ভিস ও বাচাল এন্টিটি সার্ভিস জমে যতক্ষণ না অর্কেস্ট্রেশন ও নেটওয়ার্ক বাড়তি বোঝা প্রতিটি সার্ভিসের কাজকে বামন করে। যেসব সার্ভিস সবসময় একসঙ্গে ডিপ্লয় হয়, যা ব্যবসায়িক সামর্থ্যের বদলে একটি ডেটাবেস টেবিলের কারণে আছে, বা যাদের নেটওয়ার্ক হপ এখন অনুরোধের লেটেন্সিতে প্রাধান্য পায়, তা খুঁজুন। যেখানে জনবল ও বাজেট যাচাই করা হয় সেই এন্টারপ্রাইজ ও সরকারি সম্পত্তিতে দুটি পাতলা সার্ভিসকে আবার একটি মোটা-কণা সার্ভিসে ভাঁজ করা বৈধ, খরচ-বাঁচানো পদক্ষেপ, ব্যর্থতার স্বীকারোক্তি নয়। পুনঃএকত্রীকরণকে টেবিলে রাখুন নিষ্কাশনের মতোই খোলামেলাভাবে, এবং দুটিই একই প্রমাণ দিয়ে ঠিক করুন।

4. আপনার প্ল্যাটফর্ম ও অন-কল পরিপক্বতা কি আপনার প্রস্তাবিত শৈলীকে আসলে সমর্থন করে, এবং প্রতিশ্রুতির আগে আপনি কি নির্দিষ্ট ফাঁকগুলোর নাম দিতে পারেন? মাইক্রোসার্ভিস, মেশ ও ইভেন্ট-চালিত মেরুদণ্ড তাদের সুবিধা দেয় কেবল পরিণত CI/CD, বিতরিত ট্রেসিং, সার্ভিস আবিষ্কার এবং আংশিক ব্যর্থতা নিয়ে যুক্তি করতে পারা অন-কল সংস্কৃতির ওপর। একটি বড় প্রতিষ্ঠান স্থাপত্য ফোরামে লক্ষ্য শৈলী ঠিক করে এবং পরে অনুপস্থিত প্ল্যাটফর্ম আবিষ্কার করে, যখন ডজন ডজন সার্ভিস ইতিমধ্যে প্রোডাকশনে এবং প্রতিটি ঘটনা নির্ণয়ে ঘণ্টা লাগে। স্বাধীন ডিপ্লয়মেন্ট ও স্কেলিংয়ের আকর্ষণকে ভোর ৩টায় কে এটি চালায় সেই শান্ত প্রশ্নের বিপরীতে ওজন করুন: যে ভাগ দলগুলোকে সমান্তরালে পাঠাতে মুক্ত করে, সেটিই প্রতিটি দলকে বুঝতে হওয়া ব্যর্থতার ধরনও গুণ করে। আলোচনায় সৎ তালিকা আনুন: বর্তমান ডিপ্লয়মেন্ট ফ্রিকোয়েন্সি, পুনরুদ্ধারের গড় সময়, সার্ভিস সীমানা জুড়ে ট্রেসিং আছে কি না, এবং একটি দল বাস্তবসম্মতভাবে কতগুলো সার্ভিস চালাতে পারে। এন্টারপ্রাইজ ও সরকারি পরিবেশে আপনার অনুপস্থিত প্ল্যাটফর্ম সামর্থ্যের জন্য ক্রয় ও নিয়োগের লিড টাইম যোগ করুন, কারণ আপনি অর্থায়ন না করা একটি মেশ ও প্ল্যাটফর্ম দল ধরে নেওয়া শৈলী একটি অসমর্থনযোগ্য সম্পত্তি চালানোর পরিকল্পনা।

5. ডোমেইনের কোন অংশের জন্য পূর্ণ ইভেন্ট-সোর্সড নিরীক্ষা ট্রেইল সুবিধার বদলে আইনি প্রয়োজন, এবং সিদ্ধান্ত নেওয়ার কর্তৃত্ব কার? ইভেন্ট সোর্সিং ও CQRS আপনাকে নিখুঁত, পুনর্গঠনযোগ্য ইতিহাস এবং নিজে নিজে স্কেল করা পড়ার মডেল কেনে, কিন্তু সিস্টেমের জীবনভর ইভেন্ট সংস্করণ, প্রজেকশন পুনর্নির্মাণ এবং পরিণামী সামঞ্জস্য নিয়ে যুক্তির খরচ নেয়। এমন ডোমেইনে প্রয়োগ করলে যার কখনো নিরীক্ষা ট্রেইল লাগেনি, সেই জটিলতা খাঁটি কর; যে ডোমেইনে “আমরা এই মানে কীভাবে পৌঁছালাম?” একটি আইনি প্রশ্ন সেখানে ধরে না রাখলে তার অনুপস্থিতি সম্মতি ব্যর্থতা। প্রতিদ্বন্দ্বী বিবেচনা একদিকে নিরীক্ষণযোগ্যতা ও কোয়েরি স্কেলেবিলিটি, অন্যদিকে ডিবাগিং কঠিনতা ও ডেভেলপারের জ্ঞানীয় বোঝা, তাই সিদ্ধান্ত যাঁরা নিয়ন্ত্রক বাধ্যবাধকতা ও পরিচালনগত বোঝা দুটিই বোঝেন তাঁদের, যে প্যাটার্ন নিয়ে সবচেয়ে উৎসাহী তার নয়। সুনির্দিষ্ট আইনি বা চুক্তিগত ধারণ ও পুনর্গঠনের প্রয়োজন, প্রত্যাশিত ইভেন্ট ভলিউম, এবং সংস্করণ ও প্রজেকশন কাজের সৎ অনুমান আনুন। অর্থ, কর ও সরকারে, যেখানে বছর পরে একটি সিদ্ধান্ত পুনর্গঠন করা বিধিবদ্ধ কর্তব্য হতে পারে, সেই জবাবদিহিযোগ্য মালিকের নাম দিন যিনি অনুমোদন করেন যে একটি নির্দিষ্ট বাউন্ডেড কনটেক্সটে অপরিবর্তনীয় ইভেন্ট লগ দরকার, বা দরকার নেই।

6. মডিউলার মনোলিথ ক্ষয় হওয়া কীভাবে ঠেকাবেন যাতে পরে নিষ্কাশন সস্তা থাকে, এবং কী সীমানা প্রয়োগ করবে? মডিউলার মনোলিথ দিয়ে শুরু করার পুরো যুক্তি এই প্রতিশ্রুতির ওপর দাঁড়ায় যে পরিচ্ছন্ন অভ্যন্তরীণ সীমানা পরে সার্ভিস নিষ্কাশন সাশ্রয়ী করে, তবু সময়সীমা একটি মডিউলকে অন্যটির ডেটায় হাত বাড়াতে প্রলুব্ধ করা মুহূর্তেই সেই সীমানা নিঃশব্দে ক্ষয় হয়। অনেক অবদানকারীর একটি বড় দলের জন্য শুভ উদ্দেশ্য ও কোড পর্যালোচনা একাই রেখা ধরে রাখবে না; প্রয়োগ প্রক্রিয়া ছাড়া মনোলিথ নিঃশব্দে সেই বিগ বল অব মাড হয়ে ওঠে, যা শৈলী এড়াতে চেয়েছিল। প্রয়োগ করা নির্ভরতা নিয়ম ও মডিউল ইন্টারফেসের ঘর্ষণকে ওজন করুন, বহু বছর পরে আবিষ্কারের খরচের বিপরীতে যে কোনো সীমানা বাস্তব নয় এবং প্রতিটি নিষ্কাশন মানে ভাগ করা অবস্থা জট খোলা। প্রমাণ আনুন: মডিউল সীমানা কি বিল্ড টুলিং, স্ট্যাটিক বিশ্লেষণ বা প্যাকেজ কাঠামো দিয়ে প্রয়োগ হয়, নাকি সেগুলো কেবল নথিবদ্ধ রীতি যা শেষ ছয়টি মার্জ উপেক্ষা করেছে? কঠোর পরিবর্তন-নিয়ন্ত্রণ ও কয়েক প্রজন্মের ফ্রেমওয়ার্ক টিকে থাকা দীর্ঘজীবী এন্টারপ্রাইজ ও সরকারি সিস্টেমে সীমানা প্রয়োগকে নিরীক্ষণযোগ্য নিয়ন্ত্রণ গণ্য করুন, যাতে পরে বিতরণ করার বিকল্প এমন কিছু হয় যা আপনি সত্যিই রক্ষা করেছেন, এমন নয় যা এখনো আপনার হাতে আছে বলে ধরে নিচ্ছেন।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। একটি একক মডিউলার মনোলিথ দিয়ে ডিফল্ট করুন এবং মাইক্রোসার্ভিসের টান প্রতিরোধ করুন, কারণ আপনার দুর্লভতম সম্পদ প্রকৌশল মনোযোগ এবং সার্ভিসের ঝাঁক এমন পরিচালনগত কর যা পণ্য-বাজার মিলনের আগে আপনি বহন করতে পারেন না। পরে নিষ্কাশন করতে পারার জন্য পরিচ্ছন্ন মডিউল সীমানা রাখুন, এবং যেখানে শূন্যে স্কেল ও ব্যবহার-অনুযায়ী মূল্য আপনার স্পাইকি, নিম্ন-ভিত্তিরেখা লোডের উপযোগী সেখানে সার্ভারলেস ধরুন। একটি সুনির্দিষ্ট চালক দেখা দিলেই কেবল ঠিক একটি জিনিস ভাগ করুন, যেমন একটি বার্স্টি নোটিফিকেশন প্রেরক, তার আগে কখনো নয়।

ছোট ব্যবসা। কোনো প্ল্যাটফর্ম দল নেই আর বাজেট কম, তাই একটি ম্যানেজড প্ল্যাটফর্মে একটি মনোলিথ বা হাতে-গোনা মোটা সার্ভিস পছন্দ করুন, এবং মেশ, ট্রেসিং ও সার্ভিস আবিষ্কার নিজে বানানোর বদলে হোস্টেড অবকাঠামো কিনুন। সার্ভার চালানো এড়াতে সার্ভারলেস ও ম্যানেজড ডেটাবেস ওজন করুন, এবং এমন বিতরিত নকশা থেকে সতর্ক থাকুন যার পরিচালনগত বোঝা বইবার কেউ আপনার নেই। সঠিক স্থাপত্য সেটি, যা এক বা দুজন মানুষ আসলে ডিপ্লয়, পর্যবেক্ষণ ও পুনরুদ্ধার করতে পারে।

এন্টারপ্রাইজ। আসল সমস্যা অনেক দল ও কনওয়ের সূত্র: মোটা-কণা সার্ভিস বাউন্ডেড কনটেক্সট ও দলের মালিকানার সঙ্গে সারিবদ্ধ করুন, এবং বিতরণকে নিরাপদ করা প্ল্যাটফর্মে (CI/CD, ট্রেসিং, মেশ ও সার্ভিস আবিষ্কার) ইচ্ছাকৃতভাবে বিনিয়োগ করুন। গেটওয়ে, BFF ও অভ্যন্তরীণ ক্লিন-আর্কিটেকচার প্যাটার্ন প্রমিত করুন যাতে গোষ্ঠীগুলো সেগুলো পুনরাবিষ্কার বন্ধ করে, এবং নিষ্কাশন ও পুনঃএকত্রীকরণ স্থানীয় পছন্দের বদলে প্রমাণ-ভিত্তিক পোর্টফোলিও সিদ্ধান্ত হিসেবে শাসন করুন। প্রতিটি ভাগের পরিচালনগত খরচ সুস্পষ্টভাবে বাজেট করুন, কারণ আপনার পরিসরে বিতরিত-মনোলিথ ব্যর্থতা ব্যয়বহুল এবং জট খুলতে ধীর।

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

উদাহরণ

স্টার্টআপ। একটি সময়সূচি পণ্য বানানো চারজনের একটি স্টার্টআপ মাইক্রোসার্ভিস দিয়ে শুরু করার চাপ অনুভব করে কারণ একটি প্রতিযোগী তাদের নিয়ে ব্লগ লিখেছিল, কিন্তু প্রতিরোধ করে। তারা একটি ডিপ্লয়যোগ্যে আলাদা মডিউল হিসেবে স্পষ্ট অভ্যন্তরীণ সীমানাসহ (সময়সূচি, বিলিং, নোটিফিকেশন) একটি মডিউলার মনোলিথ পাঠায়, তাই একজন ইঞ্জিনিয়ার পুরো জিনিস স্থানীয়ভাবে চালাতে পারে এবং রিলিজ একটি পুশ। পণ্য আকর্ষণ পেলে কেবল নোটিফিকেশন প্রেরক, যা বার্স্টি লোডে ইমেল ও SMS-এ ছড়ায়, নিজস্ব সার্ভিসে টেনে বের করা হয়। পণ্য-বাজার মিলন খোঁজার সময় তারা এক ডজন সার্ভিসের কোনো পরিচালনগত কর উত্তরাধিকার পায় না।

এন্টারপ্রাইজ। একটি বড় ই-কমার্স কোম্পানি মডিউলার মনোলিথ হিসেবে শুরু করে। ট্রাফিক বাড়লে ও দল গুণিত হলে সে সবচেয়ে উচ্চ-লোড, সবচেয়ে স্বাধীনভাবে বিবর্তনশীল ডোমেইন (ক্যাটালগ, কার্ট, চেকআউট ও অনুসন্ধান) আলাদা সার্ভিসে টেনে বের করে, প্রতিটি নিজের ডেটার মালিক। চেকআউট ইভেন্ট নির্গত করে যা ইনভেন্টরি, পূরণ ও বিশ্লেষণ একটি ইভেন্ট মেরুদণ্ডের মাধ্যমে ভোগ করে, ফলে নতুন ভোক্তারা (প্রতারণা শনাক্তকরণ, আনুগত্য) চেকআউট না ছুঁয়ে যুক্ত হতে পারে। একটি API গেটওয়ে auth ও হার সীমাবদ্ধকরণ সামলায়, এবং একটি BFF মোবাইলের জন্য পেলোড উপযোগী করে। বাকি কম-ট্রাফিক ডোমেইন মনোলিথে থাকে, যা অপ্রয়োজনীয় খণ্ডিতকরণ এড়ায়।

সরকার। একটি কর কর্তৃপক্ষ মূল খতিয়ানের জন্য ইভেন্ট সোর্সিংয়ে একটি মূল্যায়ন প্ল্যাটফর্ম বানায়, কারণ করদাতার দায়ের প্রতিটি পরিবর্তন বছরের পর বছর পুনর্গঠনযোগ্য ও আইনত নিরীক্ষণযোগ্য হতে হবে। কমান্ড (রিটার্ন দাখিল, পেমেন্ট প্রয়োগ, সমন্বয় ইস্যু) অপরিবর্তনীয় ইভেন্ট তৈরি করে, এবং পড়ার মডেল কর্মকর্তা ও নাগরিকদের জন্য বর্তমান ব্যালেন্স প্রজেক্ট করে। CQRS জনসাধারণ-মুখী কোয়েরি দিককে লেখার দিক ঝুঁকিতে না ফেলে দাখিলের সর্বোচ্চ মৌসুমের জন্য নিজে স্কেল করতে দেয়। ভেতরে প্রতিটি সার্ভিস ক্লিন আর্কিটেকচার অনুসরণ করে, ফলে মূল্যায়ন নিয়ম, যা প্রতিটি বাজেটে বদলায়, পারসিস্টেন্স ও মেসেজিং প্রযুক্তি থেকে আলাদা থাকে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

একটি শৈলী পছন্দে যে অর্থ ঝুঁকিতে তা বিপুল, কারণ সিদ্ধান্ত ফেরানো ব্যয়বহুল। অতি আগে মাইক্রোসার্ভিস গ্রহণ করলে আপনি প্ল্যাটফর্ম গড়ে তোলা, নকল অবকাঠামো, বিতরিত ডিবাগিং ও ভারী পরিচালন বোঝার মাধ্যমে মালিকানার মোট খরচ ফোলান: যে খরচ সিস্টেমের জীবনভর আপনার সঙ্গে থাকে। সত্যিই অতিভারী মনোলিথ ভাগ করতে অস্বীকার করলে আপনি সরবরাহ থ্রুপুটে সীমা বসান: দলগুলো একটি ভাগ করা রিলিজের পেছনে সারিতে দাঁড়ায়, এবং প্রতিটি পরিবর্তন পুরো সিস্টেমকে ঝুঁকিতে ফেলে। ROI আলোচনা আসলে পরিচালনগত ব্যয় সাংগঠনিক প্রয়োজনের সঙ্গে মেলানো নিয়ে।

নেতৃত্বের কাছে যুক্তি দিন থ্রুপুট ও ঝুঁকির ভাষায়, প্রযুক্তির নয়। স্বাধীন ডিপ্লয়যোগ্যতা মানে সমান্তরালে আরও দল পাঠানো এবং সংক্ষিপ্ততর লিড টাইম: মাপযোগ্য ব্যবসায়িক গতি। ব্যর্থতা-বিচ্ছিন্নতা মানে কম মোট বিভ্রাট এবং ছোট ক্ষতির পরিসর: মাপযোগ্য উপলব্ধতা ও সুনামের সুরক্ষা। কিন্তু প্রতিটি শৈলীর দাবি করা প্ল্যাটফর্ম বিনিয়োগ নিয়েও সমান সৎ থাকুন: একটি মেশ, ট্রেসিং ও CI/CD পরিপক্বতা পূর্বশর্ত, ঐচ্ছিক বাড়তি নয়, এবং তাদের খরচ TCO-তে পড়ে। অনেক প্রতিষ্ঠানের জন্য সস্তাতম পথ এখন একটি সুমডিউলারাইজড মনোলিথ, পরে নিষ্কাশন সস্তা করা পরিচ্ছন্ন অভ্যন্তরীণ সীমানাসহ। এটি আপনাকে বিতরণ করার বিকল্প কেনে, তার দরকার হওয়ার আগে তার দাম না দিয়ে।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• বিতরিত মনোলিথ। যে সার্ভিস অবশ্যই একসঙ্গে ডিপ্লয় করতে হয় এবং একটি ডেটাবেস ভাগ করে: বিতরণের সব খরচ, স্বাধীনতার কিছুই নয়।
• ন্যানোসার্ভিস। এত সূক্ষ্ম-কণা সার্ভিস যে অর্কেস্ট্রেশন ও নেটওয়ার্ক বাড়তি বোঝা তাদের কাজকে বামন করে।
• প্ল্যাটফর্ম ছাড়া মাইক্রোসার্ভিস। CI/CD, ট্রেসিং ও অন-কল পরিপক্বতা আসার আগে ভাগ করা; ব্যর্থতার ধরন গুণ হয়।
• এন্টিটি সার্ভিস। ব্যবসায়িক সামর্থ্যের বদলে ডেটাবেস টেবিল ধরে ভাগ (“User সার্ভিস”, “Order সার্ভিস”), প্রতিটি অপারেশনের জন্য বাচাল সার্ভিস-জোড়া কল বাধ্য করা।
• সর্বত্র ইভেন্ট সোর্সিং। যে ডোমেইনের নিরীক্ষা ট্রেইল দরকার নেই সেখানে প্রয়োগ, কোনো লাভ ছাড়াই জটিলতার কর দেওয়া।
• মনোলিথ হিসেবে গেটওয়ে। API গেটওয়েতে ব্যবসায়িক যুক্তি রাখা, কেন্দ্রীয় চোকপয়েন্ট পুনর্সৃষ্টি।
• ফ্রেমওয়ার্ক-সংযুক্ত কেন্দ্র। ব্যবসায়িক যুক্তি ওয়েব বা ORM (অবজেক্ট-রিলেশনাল ম্যাপিং) ফ্রেমওয়ার্কের সঙ্গে জট পাকানো, টেস্টিং ও প্রযুক্তি পরিবর্তন দুটিই যন্ত্রণাদায়ক করা।

পরিপক্বতা মডেল

• স্তর ১: সূচনা। শৈলী বাছা হয় ফ্যাশন বা দুর্ঘটনায়। আপনার একটি জট পাকানো মনোলিথ বা আকস্মিক বিতরিত জট আছে, সীমানা ডোমেইনের বদলে প্রযুক্তিগত স্তর বা ইতিহাস অনুসরণ করে, এবং কিছু ভাঙলে প্রতিক্রিয়ায় ভাগ ঘটে।
• স্তর ২: বিকাশ। কিছু দল মনোলিথের ভেতরে সুচিন্তিত মডিউল সীমানা আঁকে বা কয়েকটি মোটা সার্ভিস দাঁড় করায়, এবং কিছু ক্রস-কাটিং উদ্বেগ সামঞ্জস্যপূর্ণভাবে সামলানো হয়। চর্চা অসম: এক গোষ্ঠী সার্ভিস বাউন্ডেড কনটেক্সটের সঙ্গে সারিবদ্ধ করে আর অন্যটি এখনো ডেটাবেস টেবিল ধরে ভাগ করে, এবং নিষ্কাশন অ্যাড হক থাকে।
• স্তর ৩: মানসম্মতকরণ। একটি নথিবদ্ধ পদ্ধতি প্রতিষ্ঠান জুড়ে প্রয়োগ করা হয়: সার্ভিস বাউন্ডেড কনটেক্সটের সঙ্গে সারিবদ্ধ হয় ও নিজের ডেটার মালিক হয়, যথাযথ জায়গায় গেটওয়ে ও BFF প্যাটার্ন ব্যবহৃত হয়, অভ্যন্তরীণ ক্লিন বা হেক্সাগোনাল স্তরবিন্যাস মান, এবং প্রতিটি ভাগে একটি বর্ণিত চালক লাগে। মডিউল সীমানা কেবল রীতিতে নয়, টুলিং দ্বারা প্রয়োগ হয়।
• স্তর ৪: ব্যবস্থাপনা। শৈলী সিদ্ধান্ত ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। আপনি প্রতি সার্ভিসে ডিপ্লয়মেন্ট ফ্রিকোয়েন্সি ও লিড টাইম, পুনরুদ্ধারের গড় সময়, একটি সাধারণ পরিবর্তনের জন্য কতগুলো সার্ভিস একসঙ্গে ডিপ্লয় করতে হয়, এবং নেটওয়ার্ক-হপ লেটেন্সি অনুসরণ করেন, এবং প্রতিটি ভাগের খরচ সে যে স্বাধীনতা কিনতে চেয়েছিল তার বিপরীতে তুলনা করেন। প্রমাণ, পছন্দ নয়, ঠিক করে একটি সীমানা টিকবে কি না, এবং বিতরিত মনোলিথের দিকে সরে যাওয়া বিভ্রাটের বদলে মেট্রিকে ধরা পড়ে।
• স্তর ৫: সমন্বয়। স্থাপত্য সংগঠন নকশার সঙ্গে একীভূত এবং নিরন্তর খাপ-খাওয়ানো। একটি পরিণত প্ল্যাটফর্ম (CI/CD, ট্রেসিং, এবং যেখানে যথার্থ মেশ) বিতরণ ও পুনঃএকত্রীকরণ দুটিই সস্তা করে, দলগুলো চালক দেখা দিলে নিয়মিত নিষ্কাশন করে এবং চালক উধাও হলে সার্ভিস আবার ভাঁজ করে, এবং দলের গঠন, লোড ও ঝুঁকির চিত্র সরলে পুরো সম্পত্তি জুড়ে শৈলী পছন্দ পুনর্ভারসাম্যে আনা হয়।

আলোচনার ভাবনা

1. আপনার সিস্টেমের কোথায় একটি মনোলিথ আসলে শক্তি, আর কোথায় প্রকৃত বাধা?
2. আপনার পরবর্তী সার্ভিস নিষ্কাশনকে কোন সুনির্দিষ্ট চালক যথার্থ করবে, এবং তৈরির আগে আপনি কি তার নাম দিতে পারেন?
3. মাইক্রোসার্ভিসের দাবি করা পরিচালনগত পরিপক্বতা কি আপনার প্রতিষ্ঠানের আছে? কী অনুপস্থিত?
4. আপনার ডোমেইনের কোন অংশের জন্য পূর্ণ ইভেন্ট-সোর্সড নিরীক্ষা ট্রেইল আইনি বা ব্যবসায়িক প্রয়োজন বনাম থাকলে-ভালো?
5. আপনার বর্তমান সার্ভিস সীমানা আপনার দলের সীমানাকে কতটা প্রতিফলিত করে, এবং সেই সারিবদ্ধতা কি সাহায্য করছে নাকি ক্ষতি?
6. আগামী বছর আপনার ওয়েব ফ্রেমওয়ার্ক বা ডেটাবেস বদলাতে হলে আপনার ব্যবসায়িক যুক্তির কতটা পুনর্লিখন করতে হত?

প্রধান শিক্ষা

• স্থাপত্য শৈলী বাছুন আসল শক্তি (দলের আকার, ডোমেইন, লোড, পরিচালনগত পরিপক্বতা) থেকে, ফ্যাশন থেকে নয়।
• বেশিরভাগ সিস্টেমের জন্য সঠিক ডিফল্ট মডিউলার মনোলিথ; সুনির্দিষ্ট চালক সহ এবং বাউন্ডেড-কনটেক্সট রেখা ধরে কেবল সার্ভিস নিষ্কাশন করুন।
• মাইক্রোসার্ভিস স্বাধীন ডিপ্লয়মেন্ট, স্কেলিং ও ব্যর্থতা-বিচ্ছিন্নতার বিনিময়ে পরিচালনগত ও জ্ঞানীয় জটিলতা দেয়; তাদের পরিণত প্ল্যাটফর্ম লাগে।
• ইভেন্ট-চালিত, CQRS ও ইভেন্ট সোর্সিং পরিণামী সামঞ্জস্য ও সংস্করণ জটিলতার খরচে বিযুক্তি ও নিরীক্ষণযোগ্যতা দেয়; ইচ্ছাকৃতভাবে গ্রহণ করুন।
• গেটওয়ে, BFF ও মেশ অনেক-সার্ভিস সম্পত্তি বশ মানায় কিন্তু ওজন যোগ করে; স্কেল দাবি করলে আনুন, তার আগে নয়।
• মূল্যবান ব্যবসায়িক যুক্তি পরীক্ষাযোগ্য ও প্রযুক্তি পরিবর্তন জুড়ে টেকসই রাখতে প্রতিটি সার্ভিসের ভেতরে হেক্সাগোনাল/ক্লিন আর্কিটেকচার প্রয়োগ করুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Sam Newman, Building Microservices এবং Monolith to Microservices
• Chris Richardson, Microservices Patterns
• Eric Evans, Domain-Driven Design
• Vaughn Vernon, Implementing Domain-Driven Design
• Robert C. Martin, Clean Architecture
• Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
• Gregor Hohpe ও Bobby Woolf, Enterprise Integration Patterns
• Martin Fowler, Patterns of Enterprise Application Architecture (এবং CQRS ও Event Sourcing বিষয়ক নিবন্ধ)
• Matthew Skelton ও Manuel Pais, Team Topologies