3.1 স্থাপত্যের মৌলিক বিষয়

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

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

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

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

মূল নীতিসমূহ

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

সুপারিশ

গুণমান বৈশিষ্ট্য মাপযোগ্য দৃশ্যকল্প হিসেবে নির্দিষ্ট করুন

“সিস্টেম দ্রুত হওয়া উচিত” বা “অত্যন্ত উপলব্ধ”-র মতো অস্পষ্ট লক্ষ্য পরীক্ষা বা প্রয়োগ করা যায় না। তার বদলে প্রতিটি গুণমান বৈশিষ্ট্য একটি উদ্দীপক, একটি প্রসঙ্গ ও একটি মাপযোগ্য সাড়াসহ সুনির্দিষ্ট দৃশ্যকল্প হিসেবে লিখুন: “যখন সর্বোচ্চ একযোগ ব্যবহারকারী ৫০,০০০-এ পৌঁছায়, ৯৫% অনুসন্ধান অনুরোধ ৩০০ মিলিসেকেন্ডের মধ্যে সম্পন্ন হয়।” আপনার ডোমেইনের জন্য গুরুত্বপূর্ণ বৈশিষ্ট্য কভার করুন: উপলব্ধতা, পারফরম্যান্স, স্কেলেবিলিটি, নিরাপত্তা, রক্ষণাবেক্ষণযোগ্যতা, অবজার্ভেবিলিটি, অভিগম্যতা, বহনযোগ্যতা ও খরচ-দক্ষতা। এগুলো জোরে র‍্যাঙ্ক করুন, কারণ সবগুলো একসঙ্গে সর্বোচ্চ করা যায় না। সর্বোচ্চ সামঞ্জস্যের জন্য টিউন করা সিস্টেম একই সঙ্গে সর্বোচ্চ উপলব্ধ হবে না।

স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজন (ASR) চিহ্নিত করুন

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

বিবর্তনশীল স্থাপত্য ও ফিটনেস ফাংশন গ্রহণ করুন

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

C4 ও arc42 দিয়ে নথিবদ্ধ করুন

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

কাঠামোবদ্ধ বিনিময় বিশ্লেষণ চালান এবং ঝুঁকি দিয়ে নকশা চালান

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

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

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

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

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

লোডের অধীনে আপনার দুটি গুণমান বৈশিষ্ট্য সংঘর্ষে এলে কোনটি জেতে, এবং আপনি কি সেই অগ্রাধিকার ক্রম লিখে রেখেছেন? প্রতিটি স্থাপত্য বিনিময় বাধ্য করে: সর্বোচ্চ সামঞ্জস্য উপলব্ধতা খাটো করে, আঁটো নিরাপত্তা লেটেন্সি যোগ করে, আক্রমণাত্মক ক্যাশিং নিরীক্ষণযোগ্যতার সঙ্গে লড়ে। বড় দলে বিপদ হলো বিভিন্ন স্কোয়াড নিঃশব্দে ভিন্ন অগ্রাধিকার ধরে নেয়, তাই একজন থ্রুপুটের জন্য অপ্টিমাইজ করে আর অন্যজন কঠোর সামঞ্জস্য রক্ষা করে, এবং দ্বন্দ্ব প্রকাশ পায় কেবল ঘটনার সময়। এন্টারপ্রাইজ ও সরকারি পরিবেশে একজন নিয়ন্ত্রক জিজ্ঞেস করবেন আপনি কোন বৈশিষ্ট্য রক্ষা করেছেন এবং কেন, তাই ক্রম লোককথার বদলে সুস্পষ্ট ও রক্ষণযোগ্য হতে হবে। আপনার গুণমান-বৈশিষ্ট্য দৃশ্যকল্প আনুন এবং জোড়া ধরে জোরে র‍্যাঙ্ক করুন যতক্ষণ না ক্রম দ্ব্যর্থহীন হয়। তারপর বিজয়ীকে একটি ফিটনেস ফাংশনে এনকোড করুন যাতে অগ্রাধিকার সময়সীমার চাপে ক্ষয় না হয়ে টিকে থাকে।
আপনার সাম্প্রতিক কোন সিদ্ধান্তগুলো একমুখী দরজা ছিল, এবং সেগুলো কি দ্বিমুখী দরজার চেয়ে বেশি যাচাই পেয়েছিল? ঝুঁকি-চালিত নকশা বলে একটি সিদ্ধান্ত ফেরানো কতটা কঠিন তার অনুপাতে নকশা পরিশ্রম ব্যয় করতে, তবু বেশিরভাগ দল প্রতিটি পরিবর্তন প্রায় একই আনুষ্ঠানিকতায় পর্যালোচনা করে। এটি সস্তা, ফেরানো-যায় পছন্দে মনোযোগ অপচয় করে, অথচ অপরিবর্তনীয়গুলো (আইনি রেকর্ডে গাঁথা একটি ডেটা মডেল, একটি পাবলিক API চুক্তি, একটি মূল ডেটাস্টোর) খুব কম চ্যালেঞ্জ নিয়ে পার হয়ে যায়। গত ত্রৈমাসিকের তাৎপর্যপূর্ণ সিদ্ধান্ত টেনে ফিরানোর সহজতা অনুযায়ী বাছাই করুন, তারপর জিজ্ঞেস করুন অপরিবর্তনীয়গুলো প্রোটোটাইপ, স্পাইক বা আনুষ্ঠানিক পর্যালোচনা পেয়েছিল কি না। দীর্ঘজীবী এন্টারপ্রাইজ ও সরকারি সিস্টেমে একটি ভুল একমুখী দরজার খরচ এক দশক ধরে চক্রবৃদ্ধি হয়, তাই বাড়তি কঠোরতা বহুগুণ ফেরত দেয়। আপনার প্রক্রিয়ার ভার সিদ্ধান্তের ফেরানো-যোগ্যতার সঙ্গে মেলান, ডিফের আকারের সঙ্গে নয়।
আপনার পরবর্তী উচ্চ-ঝুঁকির, ফেরানো-কঠিন সিদ্ধান্তের জন্য কার কার ঘরে থাকা দরকার, এবং কোন দৃশ্যকল্পের বিপরীতে আপনি বিকল্পগুলো স্কোর করবেন? ATAM-শৈলীর কাঠামোবদ্ধ বিনিময় পর্যালোচনা তার খরচ অর্জন করে যখন একটি সিদ্ধান্ত অপরিবর্তনীয় এবং একসঙ্গে বেশ কয়েকটি গুণমান বৈশিষ্ট্য ছোঁয়, এবং তার শক্তি আসে উপস্থিত মানুষদের থেকে: সরবরাহ, নিরাপত্তা, পরিচালন, এবং যে নীতি বা ব্যবসায়িক মালিকরা পরিণতি অনুভব করেন। এর একটি কণ্ঠ বাদ দিলে আপনি বিল্ডের পরে দ্বন্দ্ব আবিষ্কার করেন, যেভাবে একটি ক্যাশিং পছন্দ নিঃশব্দে একটি নিরীক্ষণযোগ্যতা প্রয়োজন ভেঙে দিতে পারে। অগ্রাধিকার দেওয়া গুণমান-বৈশিষ্ট্য দৃশ্যকল্প স্কোরিং রুব্রিক হিসেবে আনুন, এবং এমন সংবেদনশীলতা বিন্দু খুঁজুন যেখানে একটি বিকল্প একটি বৈশিষ্ট্যকে প্রবলভাবে দোলায় এবং বিনিময় বিন্দু যেখানে সেটি একাধিককে সরায়। আপনি যে ফল চান তা হলো একটি সংক্ষিপ্ত ADR যা বাতিল করা বিকল্প ও কেন তা লিপিবদ্ধ করে, যাতে যুক্তি তা নেওয়া মানুষদের ছাড়িয়ে টেকে। আসন্ন কোনো সিদ্ধান্ত এটি যথার্থ করে বলে মনে না হলে সেটিই পরীক্ষা করার মতো, কারণ দিগন্তে কোনো অপরিবর্তনীয় সিদ্ধান্ত না থাকা একটি বড় কর্মসূচি সাধারণত যথেষ্ট দূরে তাকাচ্ছে না।
কোনো নতুন যোগদানকারী বা বাইরের নিরীক্ষকের কাছে কেবল আপনার লিখিত স্থাপত্য থাকলে তারা কি সিস্টেম কেন এই আকারের তা পুনর্গঠন করতে পারতেন, এবং আপনি শেষ কবে তা পরীক্ষা করেছেন? কয়েকজন জ্যেষ্ঠের মাথায় বাস করা স্থাপত্য একটি একক ব্যর্থতার বিন্দু: সেই মানুষরা সরে গেলে প্রতিটি ফেরানো-কঠিন সিদ্ধান্তের পেছনের যুক্তিও তাদের সঙ্গে যায়, এবং পরের দল ঘটনার মাধ্যমে তা আবার শেখে। একটি বড় প্রতিষ্ঠানের জন্য স্থাপত্যের পাঠযোগ্যতা (বাস্তবের সঙ্গে মেলা C4 চিত্র, একটি arc42 বর্ণনা, বাতিল বিকল্প লিপিবদ্ধ করা ADR) ডজন ডজন দলকে মিটিং ছাড়াই একই সিস্টেম নিয়ে যুক্তি করতে দেয়। একটি সাম্প্রতিক ADR ও একটি বর্তমান চিত্র আনুন, উপাদানটি যে বানায়নি এমন কাউকে দিন, এবং দেখুন একজন মানুষকে প্রশ্ন করার আগে তারা কতদূর যান। এন্টারপ্রাইজ ও সরকারি পরিবেশে একজন নিরীক্ষক ঠিক এই অনুশীলনই করবেন, এবং গত বছরের সিস্টেম বর্ণনা করা ডকুমেন্টেশন না থাকার চেয়ে খারাপ কারণ এটি ঠিক যাঁদের সনদ দিতে হবে তাঁদের বিভ্রান্ত করে। লিখিত রেকর্ডের সতেজতা মাপযোগ্য বৈশিষ্ট্য গণ্য করুন, এবং তা সত্য রাখার পেছনে একটি ফিটনেস ফাংশন বা পর্যালোচনা ছন্দ রাখুন।
আপনার স্থাপত্য বৈশিষ্ট্যের কোনগুলো আজ একটি স্বয়ংক্রিয় ফিটনেস ফাংশন দিয়ে সুরক্ষিত, আর কোনগুলো এখনো সবার নিয়ম মনে রাখার ওপর নির্ভর করে? শুধু একটি উইকি পাতা বা পর্যালোচকের স্মৃতিতে বাস করা অভিপ্রায় সময়সীমা এলেই ক্ষয় হয়, কারণ স্তরবিন্যাসের নিয়ম, ভাগ-করা-ডেটাবেস-নেই সীমানা এবং লেটেন্সি বাজেটই ঠিক সেই জিনিস যা দল চাপে থাকলে কাটে। একটি বড়, দ্রুত-বদলানো কোডবেসে একমাত্র যে অভিপ্রায় টিকে থাকে তা বিল্ড যা প্রয়োগ করে, তাই আপনি যে বৈশিষ্ট্য দাবি করেন এবং যেগুলো আসলে যাচাই করেন তাদের মধ্যকার ফাঁকই আপনার প্রকৃত স্থাপত্যিক ঝুঁকি। আপনার তাৎপর্যপূর্ণ বৈশিষ্ট্যগুলো তালিকাভুক্ত করুন, প্রতিটি প্রয়োগকৃত, হাতে-পর্যালোচিত বা অসুরক্ষিত চিহ্নিত করুন, এবং শেষ তিনবার যখন একটি পর্যালোচনা এমন সরে যাওয়া ধরেছে যা একটি ফিটনেস ফাংশন আগেই ধরতে পারত তা আনুন। নিয়ন্ত্রিত ও সরকারি সিস্টেমে এটি দ্বিগুণ গুরুত্বপূর্ণ, কারণ একজন নিয়ন্ত্রক জিজ্ঞেস করবেন না আপনি ডেটার আবাসন বা নিরীক্ষণযোগ্যতা চেয়েছিলেন কি না, বরং তা নিরন্তর টিকেছিল তা কীভাবে প্রমাণ করেন, এবং একটি সবুজ পাইপলাইন নীতি নথির চেয়ে অনেক শক্তিশালী উত্তর। যে বৈশিষ্ট্যের ব্যর্থতা একসঙ্গে সম্ভাব্য ও ব্যয়বহুল সেগুলো স্বয়ংক্রিয় করাকে অগ্রাধিকার দিন, এবং মেনে নিন যে কিছু হাতেই থাকবে।
একটি প্রয়োজন স্থাপত্যগতভাবে তাৎপর্যপূর্ণ কি না তা যখন ঠিক করেন, সেই সিদ্ধান্ত কে নেয়, এবং ASR তালিকা সবকিছু বা কিছুই-না হয়ে যাওয়া কীভাবে ঠেকান? স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজনের নাম দেওয়ার মূল্য আসে নির্বাচনধর্মিতা থেকে: প্রতিটি প্রয়োজনকে তাৎপর্যপূর্ণ ধরলে নকশা থমকে যায়, কোনোটিকেই না ধরলে কাঠামোগত, ঝুঁকিপূর্ণ, বদলানো-কঠিনগুলো অসুরক্ষিত পার হয়ে যায়। একটি বড় দলে প্রলোভন হলো প্রতিটি স্কোয়াডকে স্থানীয়ভাবে ঠিক করতে দেওয়া, যা অসঙ্গত মান এবং দল-জোড়া বিস্ময় তৈরি করে যখন এক গোষ্ঠীর “ছোট” পছন্দ অন্যের কাঠামোকে সীমিত করে। আপনার বর্তমান ASR তালিকা, আপনি যে মানদণ্ড ব্যবহার করেছেন (অনেক উপাদান ছোঁয়, পূরণে ব্যয়বহুল, কঠোর সীমাবদ্ধতা, প্রযুক্তিগতভাবে ঝুঁকিপূর্ণ), এবং সীমানা জোরে পরীক্ষা করতে কয়েকটি সীমান্তবর্তী প্রয়োজন আনুন। এন্টারপ্রাইজ ও সরকারের জন্য ডেটার আবাসন, ধারণ ও নিরীক্ষণযোগ্যতার মতো নিয়ন্ত্রক আদেশ প্রায় সবসময় তাৎপর্যপূর্ণ ও আলোচনাযোগ্য নয়, তাই নাম দিন তালিকার মালিক কে, কীভাবে তা পর্যালোচিত হয়, এবং একটি ASR যোগ বা বাদ দেওয়ার সিদ্ধান্ত কীভাবে লিপিবদ্ধ হয়, কারণ যে ASR কেউ শাসন করে না তা এমন প্রয়োজন, যা যাচাইয়ের মুখে কেউ রক্ষা করবে না।

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

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

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

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

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

উদাহরণ

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

এন্টারপ্রাইজ। একটি বহুজাতিক ব্যাংক বারোটি আঞ্চলিক পেমেন্ট সিস্টেম একীভূত করছে, তাই সে একটি ছোট স্থাপত্য গিল্ড গড়ে। গিল্ড আটটি গুণমান-বৈশিষ্ট্য দৃশ্যকল্প সংজ্ঞায়িত করে (“কোনো লেনদেন না হারিয়ে প্রতি সেকেন্ডে ১০,০০০ লেনদেন প্রক্রিয়া” এবং “১৫ মিনিটে একটি অঞ্চল পুনরুদ্ধার” সহ), প্রায় চল্লিশটি ADR ধারণ করে, এবং CI-তে (কন্টিনিউয়াস ইন্টিগ্রেশন) ফিটনেস ফাংশন প্রয়োগ করে: কোনো সার্ভিস অন্য ডোমেইনের ডেটাবেসে লিখতে পারবে না, সব সার্ভিস-আন্তঃকল ট্রেস করা হবে, এবং একটি জটিল CVE (Common Vulnerabilities and Exposures) সহ যেকোনো নির্ভরতা বিল্ড ব্যর্থ করবে। C4 প্রসঙ্গ ও কন্টেইনার চিত্র প্রতিটি নকশা পর্যালোচনায় ভাগ করা মানচিত্র হয়, এবং দল-জোড়া ইন্টিগ্রেশন বিরোধ তীব্রভাবে কমে।

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

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

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

নেতৃত্বের জন্য যুক্তি বিকল্প ও ঝুঁকির চারপাশে কাঠামো করুন। ভালো স্থাপত্যের মৌলিক বিষয় ভবিষ্যৎ পরিবর্তনের খরচ কমায় (দশকব্যাপী সিস্টেম জীবনে সরবরাহ গতি ও মালিকানার মোট খরচের সরাসরি লিভার), গুরুতর ঘটনা কত ঘন ঘন ও কত দীর্ঘ হয় তা কমায়, এবং নিয়ন্ত্রক ও নিরীক্ষকরা এখন যে ডকুমেন্টেশন ধারা দাবি করেন তা তৈরি করে। ADR অভ্যাস একাই নিজের দাম তোলে প্রথমবার যখন নতুন নেতৃত্ব দল জিজ্ঞেস করে “আমরা এটি এভাবে কেন বানালাম?” এবং ফরেনসিক তদন্তের বদলে মিনিটে উত্তর পায়। যেখানে পারেন সংখ্যা দিন: এড়ানো একটি বড় পুনঃস্থাপত্য, বা এড়ানো একটি ব্যর্থ নিরীক্ষার খরচ, চর্চার ছোট চলমান খরচের বিপরীতে ওজন করুন।

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

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

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

স্তর ১: সূচনা। স্থাপত্য অন্তর্নিহিত এবং ব্যক্তিদের মাথায় বাস করে। কোনো নথিবদ্ধ গুণমান বৈশিষ্ট্য, ADR বা ভাগ করা চিত্র নেই। কাঠামো আবিষ্কৃত হয় ঘটনার সময়, এবং প্রতিটি দল-জোড়া নির্ভরতা স্ক্র্যাচ থেকে আবার দর-কষাকষি হয়।
স্তর ২: বিকাশ। কিছু দল ফেরানো যন্ত্রণাদায়ক সিদ্ধান্ত লিখে রাখে এবং মূল চিত্র স্কেচ করে, কিন্তু চর্চা অসঙ্গত: এক স্কোয়াড ADR রাখে আর অন্যটি কিছুই না, গুণমান বৈশিষ্ট্য মাপযোগ্য দৃশ্যকল্পের বদলে বিশেষণ হিসেবে নাম পায়, এবং ডকুমেন্টেশন প্রকল্পের মধ্যে পুরোনো হয়ে যায়।
স্তর ৩: মানসম্মতকরণ। গুণমান-বৈশিষ্ট্য দৃশ্যকল্প ও স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজন একটি নথিবদ্ধ, প্রতিষ্ঠান-ব্যাপী মানে নির্দিষ্ট ও অগ্রাধিকারপ্রাপ্ত। ADR রুটিন এবং কোডের পাশে সংরক্ষিত, C4 ও arc42 ডকুমেন্টেশন একটি সাধারণ টেমপ্লেটে রক্ষিত, এবং প্রতিটি দল জুড়ে তাৎপর্যপূর্ণ সিদ্ধান্তের জন্য কাঠামোবদ্ধ বিনিময় পর্যালোচনা বাধ্যতামূলক।
স্তর ৪: ব্যবস্থাপনা। স্থাপত্য দাবির বদলে ভিত্তিরেখার বিপরীতে মাপা হয়। CI-তে ফিটনেস ফাংশন p99 লেটেন্সি, স্তরবিন্যাস লঙ্ঘন, ট্রেস-না-করা কল ও দুর্বল নির্ভরতার মতো বৈশিষ্ট্যের প্রতিবেদন দেয়; ADR কভারেজ ও ডকুমেন্টেশন সতেজতা মেট্রিক হিসেবে অনুসরণ করা হয়; বিনিময় পর্যালোচনা অগ্রাধিকারপ্রাপ্ত দৃশ্যকল্পের বিপরীতে বিকল্প স্কোর করে; এবং সম্মত ভিত্তিরেখার বিপরীতে সরে যাওয়া বিস্ময়ের বদলে একটি সংজ্ঞায়িত সাড়া ট্রিগার করে। নিরীক্ষকরা কেবল বর্ণনার বদলে মাপা প্রমাণের ওপর নির্ভর করতে পারেন।
স্তর ৫: সমন্বয়। স্থাপত্য পুরো প্রতিষ্ঠান জুড়ে নিরন্তর ও খাপ-খাওয়া ধরনে বিবর্তিত হয়। ফিটনেস-ফাংশন ও ঘটনার তথ্য ফিরে জানায় কোন বৈশিষ্ট্য গুরুত্বপূর্ণ এবং নকশা পরিশ্রম কোথায় যায়; আদেশ ও ঝুঁকি সরলে ASR তালিকা, গুণমান-বৈশিষ্ট্য অগ্রাধিকার ও সুরক্ষাবেষ্টনী নতুন পরিসর পায়; এবং চর্চা সরবরাহ, নিরাপত্তা ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত, তাই প্ল্যাটফর্ম স্ক্র্যাচ থেকে পুনর্নির্মিত না হয়ে নতুন প্রয়োজনে খাপ খায়।

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

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

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

স্থাপত্য হলো ফেরানো ব্যয়বহুল সিদ্ধান্তের সমষ্টি; সেই বিনিময় সুচিন্তিতভাবে করুন এবং লিপিবদ্ধ করুন।
গুণমান বৈশিষ্ট্য মাপযোগ্য দৃশ্যকল্প হিসেবে নির্দিষ্ট করুন এবং যে স্থাপত্যগতভাবে তাৎপর্যপূর্ণ প্রয়োজন কাঠামো গড়ে তা চিহ্নিত করুন।
ক্রমবর্ধমানভাবে নকশা করুন এবং স্বয়ংক্রিয় ফিটনেস ফাংশন দিয়ে মূল স্থাপত্য বৈশিষ্ট্য রক্ষা করুন।
C4 চিত্র, একটি arc42 বর্ণনা, এবং কোডের পাশে রাখা প্রতি-সিদ্ধান্ত ADR দিয়ে হালকা কিন্তু সত্যনিষ্ঠভাবে নথিবদ্ধ করুন।
কঠোরতা ঝুঁকির সঙ্গে মেলান: অপরিবর্তনীয়, উচ্চ-প্রভাব সিদ্ধান্তে ভারী বিশ্লেষণ; অন্যত্র হালকা প্রক্রিয়া।
ব্যবসায়িক যুক্তি হলো এড়ানো পুনর্কাজ, সংক্ষিপ্ততর ঘটনা, দ্রুততর ভবিষ্যৎ পরিবর্তন এবং নিরীক্ষা-প্রস্তুত প্রমাণ।

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

Len Bass, Paul Clements ও Rick Kazman, Software Architecture in Practice
Neal Ford, Rebecca Parsons ও Patrick Kua, Building Evolutionary Architectures
Simon Brown, Software Architecture for Developers (এবং C4 মডেল)
Mark Richards ও Neal Ford, Fundamentals of Software Architecture
George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach
Michael Nygard, “Documenting Architecture Decisions” (ADR প্যাটার্ন)
Gernot Starke ও Peter Hruschka, arc42 documentation template
Paul Clements et al., Evaluating Software Architectures: Methods and Case Studies (ATAM)
ISO/IEC 25010, Systems and software quality models