4. সিস্টেম কনস্ট্রেইন্টস (System Constraints) — বিস্তারিত ব্যাখ্যা

সফটওয়্যার আর্কিটেকচার ডিজাইন করার সময় আমরা যেমন Functional Requirements ও Quality Attributes নির্ধারণ করি, তেমনি কিছু “Constraint” বা সীমাবদ্ধতাও বিবেচনা করতে হয়।

এই Constraints হলো এমন কিছু শর্ত বা নিয়ম যা আর্কিটেক্টের স্বাধীনতা সীমিত করে —
অর্থাৎ, সিস্টেম ডিজাইন করার সময় আপনি যেভাবে খুশি সিদ্ধান্ত নিতে পারবেন না;
বরং কিছু বাধ্যতামূলক বিষয় অনুসরণ করতে হবে।

---

🔸 ১. System Constraint কী?

System Constraint হলো এমন কোনো শর্ত, সীমাবদ্ধতা বা নিয়ম যা আপনার সফটওয়্যার ডিজাইন, ইমপ্লিমেন্টেশন বা ডিপ্লয়মেন্ট প্রক্রিয়ায় প্রভাব ফেলে।

👉 সহজভাবে বলতে গেলে:

“Constraint মানে হলো — আপনি কোন জিনিসটি করতেই হবে বা করতে পারবেন না — এমন সীমাবদ্ধতা।”

---

🔸 ২. কেন System Constraint গুরুত্বপূর্ণ?

কারণ এগুলো নির্ধারণ করে দেয় —

• আপনি কোন প্রযুক্তি ব্যবহার করতে পারবেন

• আপনার সিস্টেম কোথায় হোস্ট হবে

• কত বাজেটের মধ্যে থাকতে হবে

• নিরাপত্তা বা আইনগত কোনো সীমাবদ্ধতা মানতে হবে কিনা

একজন আর্কিটেক্টের কাজ হলো, এই Constraints গুলো চিনে নিয়ে সেগুলোর ভেতরে থেকেই সেরা সম্ভাব্য ডিজাইন তৈরি করা।

---

🔸 ৩. System Constraints-এর প্রকারভেদ

System Constraints সাধারণত কয়েকটি বড় দলে ভাগ করা যায় 👇

🟢 ১. Technological Constraints (প্রযুক্তিগত সীমাবদ্ধতা)

এই সীমাবদ্ধতাগুলো বলে দেয় — কোন প্রযুক্তি, টুল, বা ফ্রেমওয়ার্ক ব্যবহার করা যাবে বা যাবে না।

উদাহরণ:

• কোম্পানি শুধুমাত্র .NET প্রযুক্তি ব্যবহার করবে

• ডাটাবেস হিসেবে শুধুমাত্র SQL Server অনুমোদিত

• ক্লাউড হিসেবে শুধু Azure ব্যবহার করতে হবে (AWS নয়)

অর্থাৎ, আপনি চাইলে Python বা MongoDB ব্যবহার করতে পারবেন না — কারণ কোম্পানির নীতিতে তা নিষিদ্ধ।

---

🟢 ২. Business Constraints (ব্যবসায়িক সীমাবদ্ধতা)

এই সীমাবদ্ধতা মূলত বাজেট, সময়, ও ব্যবসায়িক লক্ষ্য থেকে আসে।

উদাহরণ:

• প্রকল্পটি ৩ মাসের মধ্যে ডেলিভার করতে হবে

• সর্বোচ্চ ২০ লাখ টাকার বাজেট

• প্রোডাক্টটি অবশ্যই বিদ্যমান ERP সিস্টেমের সাথে ইন্টিগ্রেটেড হতে হবে

অর্থাৎ, আপনি যত ভালো ডিজাইনই করুন, সময় ও বাজেটের সীমাবদ্ধতা অতিক্রম করা যাবে না।

---

🟢 ৩. Organizational Constraints (সংগঠনগত সীমাবদ্ধতা)

প্রতিটি প্রতিষ্ঠানের নিজস্ব নীতিমালা, সিকিউরিটি রুল, বা অ্যাপ্রুভাল প্রক্রিয়া থাকতে পারে।

উদাহরণ:

• সব অ্যাপ্লিকেশনকে কোম্পানির single sign-on (SSO) ব্যবহার করতে হবে

• সার্ভার অ্যাক্সেস কেবল DevOps টিমের মাধ্যমে হবে

• কোড রিভিউ না হলে কোনো পরিবর্তন মার্জ করা যাবে না

---

🟢 ৪. Legal & Regulatory Constraints (আইনগত সীমাবদ্ধতা)

এই সীমাবদ্ধতা আসে দেশ, প্রতিষ্ঠান বা ক্লায়েন্টের আইনগত নীতিমালা থেকে।

উদাহরণ:

• ইউরোপীয় গ্রাহকদের তথ্য GDPR অনুযায়ী সংরক্ষণ করতে হবে

• গ্রাহকের ডেটা দেশীয় সার্ভারে রাখতে হবে (offshore নয়)

• কোনো ধরনের user tracking করতে গেলে user consent নিতে হবে

অর্থাৎ, আইন না মানলে কোম্পানি জরিমানা বা নিষেধাজ্ঞার মুখে পড়তে পারে।

---

🟢 ৫. Operational Constraints (কার্যক্রম ভিত্তিক সীমাবদ্ধতা)

এই ধরনের সীমাবদ্ধতা সিস্টেমের অপারেশন বা ইনফ্রাস্ট্রাকচার সম্পর্কিত।

উদাহরণ:

• সার্ভার ডাউনটাইম সর্বোচ্চ ৫ মিনিটের বেশি হতে পারবে না

• সিস্টেম অবশ্যই ২৪/৭ উপলব্ধ থাকতে হবে

• ব্যাকআপ নিতে হবে প্রতিদিন রাত ১২টায় স্বয়ংক্রিয়ভাবে

---

🔸 ৪. বাস্তব উদাহরণ

ধরুন আপনি একটি Banking System ডিজাইন করছেন।
এখানে কিছু System Constraints হতে পারে 👇

---

🔸 ৫. System Constraints কিভাবে আর্কিটেকচারে প্রভাব ফেলে

Constraints আসলে আর্কিটেকচারের সীমা টেনে দেয়,
যার মধ্যে থেকেই আপনাকে সেরা ডিজাইন তৈরি করতে হয়।

উদাহরণস্বরূপ —

• যদি কোম্পানি বলে “শুধু .NET ব্যবহার করতে হবে”, তাহলে আপনি Java বা Python বেছে নিতে পারবেন না।

• যদি বাজেট সীমিত হয়, তাহলে হয়তো আপনি Azure Kubernetes নয়, Container Apps ব্যবহার করবেন।

• যদি Security constraint থাকে, তাহলে আপনাকে অতিরিক্ত এনক্রিপশন ও access control যুক্ত করতে হবে।

👉 অর্থাৎ, Constraints ডিজাইনের freedom কমায়, কিন্তু সিস্টেমকে বাস্তবজীবনের সীমার ভেতরে রাখে।

---

🔸 ৬. উপসংহার

System Constraints হলো বাস্তবজীবনের নিয়ম ও সীমাবদ্ধতা,
যেগুলোকে উপেক্ষা করলে একটি আর্কিটেকচার অবাস্তব বা অকার্যকর হয়ে যায়।

একজন দক্ষ সফটওয়্যার আর্কিটেক্টকে অবশ্যই —

“Requirement + Quality Attribute + Constraints”
এই তিনটি বিষয় একত্রে বিশ্লেষণ করে সঠিক সিদ্ধান্ত নিতে হয়।

---

💡 সংক্ষেপে মনে রাখুন: