ফ্রন্টএন্ড ডেভেলপাররা প্রায়ই অ্যাপ্লিকেশন আর্কিটেকচার সম্পর্কিত একটি সমস্যার সম্মুখীন হন। এটির জন্য একটি আর্কিটেকচারের ব্যবহার প্রয়োজন যা সহজেই স্কেল করতে পারে এবং আলগা কাপলিং এবং অ্যাপ্লিকেশন মডিউলগুলির মধ্যে উচ্চ সমন্বয় প্রদান করতে পারে।
এই নিবন্ধটি বৈশিষ্ট্য-স্লাইসড ডিজাইন আর্কিটেকচার নিয়ে আলোচনা করে, কারণ, আমার মতে, উপলব্ধ বিকল্পগুলির মধ্যে এটি সেরা। এটি FSD-এর ধারণা এবং এই স্থাপত্য পদ্ধতিতে যে সমস্যাগুলি সমাধান করে তাও অন্বেষণ করে৷
আমরা ক্লাসিক্যাল এবং মডুলার আর্কিটেকচারের সাথে FSD-এর তুলনা করব এবং তাদের ভালো-মন্দ পরীক্ষা করব।
প্রথম এবং সর্বাগ্রে, আসুন তিনটি ধারণাকে আলাদা করা যাক: স্তর, স্লাইস এবং সেগমেন্ট।
স্তরগুলি হল শীর্ষ-স্তরের ডিরেক্টরি এবং অ্যাপ্লিকেশন পচনের প্রথম স্তর। এগুলি সংখ্যায় সীমিত - সর্বাধিক 7 স্তর - এবং প্রমিত, যদিও কিছু ঐচ্ছিক।
বর্তমানে, নিম্নলিখিত স্তরগুলি আলাদা করা হয়েছে:
প্রতিটি স্তরের দায়িত্বের নিজস্ব অঞ্চল রয়েছে এবং এটি ব্যবসা-ভিত্তিক। আসুন প্রতিটি স্তরকে আলাদাভাবে বিবেচনা করি।
এই স্তরগুলি কোডবেসকে সংগঠিত করতে এবং একটি মডুলার, রক্ষণাবেক্ষণযোগ্য এবং মাপযোগ্য আর্কিটেকচারকে প্রচার করতে সহায়তা করে।
ফিচার-স্লাইসড ডিজাইনের মূল বৈশিষ্ট্যগুলির মধ্যে একটি হল এর ক্রমিক কাঠামো। এই কাঠামোতে, সত্তাগুলি বৈশিষ্ট্যগুলি থেকে কার্যকারিতা ব্যবহার করতে পারে না কারণ বৈশিষ্ট্যগুলি শ্রেণিবিন্যাসে উচ্চতর।
একইভাবে, বৈশিষ্ট্যগুলি উইজেট বা প্রক্রিয়াগুলির উপাদানগুলি ব্যবহার করতে পারে না, কারণ উপরের স্তরগুলি কেবল নীচের স্তরগুলিকে ব্যবহার করতে পারে৷ এটি একটি রৈখিক প্রবাহ বজায় রাখার জন্য করা হয় যা শুধুমাত্র এক দিকে পরিচালিত হয়। ক্রমানুসারে একটি স্তর যত নিচের অবস্থানে থাকবে, তাতে পরিবর্তন করা তত ঝুঁকিপূর্ণ হবে কারণ কোডের আরও জায়গায় এটি ব্যবহার করার সম্ভাবনা রয়েছে। উদাহরণস্বরূপ, ভাগ করা স্তরের UI কিট বৈশিষ্ট্য, উইজেট এবং এমনকি পৃষ্ঠা স্তরগুলিতে ব্যবহৃত হয়।
প্রতিটি স্তরে, উপ-নির্দেশিকা রয়েছে - স্লাইস - অ্যাপ্লিকেশন পচনের দ্বিতীয় স্তর। স্লাইসে, সংযোগটি বিমূর্ত জিনিসগুলির সাথে নয় তবে নির্দিষ্ট ব্যবসায়িক সত্তার সাথে। স্লাইসের মূল লক্ষ্য হল তার মান অনুসারে গ্রুপ কোড করা।
স্লাইস নামগুলি প্রমিত নয়, কারণ সেগুলি সরাসরি প্রকল্পের ব্যবসায়িক এলাকা দ্বারা নির্ধারিত হয়। উদাহরণস্বরূপ, একটি ফটো গ্যালারিতে, ফটো, অ্যালবাম এবং গ্যালারির মতো বিভাগ থাকতে পারে। একটি সামাজিক নেটওয়ার্কের জন্য পোস্ট, ব্যবহারকারী এবং নিউজফিডের মতো স্লাইস প্রয়োজন হবে।
ঘনিষ্ঠভাবে সম্পর্কিত টুকরাগুলিকে একটি ডিরেক্টরিতে কাঠামোগতভাবে গোষ্ঠীভুক্ত করা যেতে পারে, তবে তাদের অবশ্যই অন্যান্য স্লাইসের মতো একই বিচ্ছিন্নতা নিয়ম মেনে চলতে হবে - এই ডিরেক্টরিতে কোডে কোনও ভাগ করা অ্যাক্সেস থাকা উচিত নয়৷
প্রতিটি স্লাইস সেগমেন্ট নিয়ে গঠিত। বিভাগগুলি কোডটিকে তার উদ্দেশ্যের উপর ভিত্তি করে একটি স্লাইসের মধ্যে ভাগ করতে সহায়তা করে। দলের চুক্তির উপর নির্ভর করে, বিভাগগুলি রচনা এবং নামকরণে পরিবর্তন হতে পারে। নিম্নলিখিত বিভাগগুলি সাধারণত ব্যবহৃত হয়:
প্রতিটি স্লাইস এবং সেগমেন্টের একটি পাবলিক API আছে। পাবলিক API একটি index.js বা index.ts ফাইল দ্বারা প্রতিনিধিত্ব করা হয়, যা স্লাইস বা সেগমেন্ট থেকে বাইরের দিকে শুধুমাত্র প্রয়োজনীয় কার্যকারিতা বের করতে এবং অপ্রয়োজনীয় কার্যকারিতা বিচ্ছিন্ন করার অনুমতি দেয়। ইনডেক্স ফাইলটি একটি এন্ট্রি পয়েন্ট হিসাবে কাজ করে।
পাবলিক API এর জন্য নিয়ম:
পাবলিক API আমদানি এবং রপ্তানির সাথে কাজকে সহজ করে, তাই অ্যাপ্লিকেশনে পরিবর্তন করার সময়, কোডের সর্বত্র আমদানি পরিবর্তন করার প্রয়োজন নেই।
স্তরটি যত বেশি হবে, তত বেশি এটি নির্দিষ্ট ব্যবসায়িক নোডের সাথে আবদ্ধ হবে এবং এতে আরও বেশি ব্যবসায়িক যুক্তি থাকবে। স্তর যত কম হবে তত বেশি বিমূর্ততা, পুনঃব্যবহারযোগ্যতা এবং স্তরে স্বায়ত্তশাসনের অভাব।
ফিচার-স্লাইসড ডিজাইনের কাজগুলির মধ্যে একটি হল লুজ কাপলিং এবং উচ্চ সংহতি অর্জন করা। FSD কিভাবে এই ফলাফল অর্জন করে তা বোঝা গুরুত্বপূর্ণ।
ওওপি-তে, এই সমস্যাগুলি বহুকাল ধরে পলিমরফিজম , এনক্যাপসুলেশন , ইনহেরিট্যান্স এবং অ্যাবস্ট্রাকশনের মতো ধারণার মাধ্যমে সমাধান করা হয়েছে। এই ধারণাগুলি কোডের বিচ্ছিন্নতা, পুনঃব্যবহারযোগ্যতা এবং বহুমুখিতা নিশ্চিত করে, যেখানে একটি উপাদান বা কার্যকারিতা কীভাবে ব্যবহার করা হয় তার উপর নির্ভর করে বিভিন্ন ফলাফল পাওয়া যায়।
ফিচার-স্লাইসড ডিজাইন ফ্রন্টএন্ডে এই নীতিগুলি প্রয়োগ করতে সাহায্য করে।
বিমূর্ততা এবং বহুরূপতা স্তরের মাধ্যমে অর্জন করা হয়। যেহেতু নীচের স্তরগুলি বিমূর্ত, সেগুলি উচ্চ স্তরগুলিতে পুনরায় ব্যবহার করা যেতে পারে এবং শর্তগুলির উপর নির্ভর করে, নির্দিষ্ট প্যারামিটার বা প্রপসের উপর ভিত্তি করে একটি উপাদান বা কার্যকারিতা ভিন্নভাবে কাজ করতে পারে।
পাবলিক API-এর মাধ্যমে এনক্যাপসুলেশন অর্জন করা হয়, যা বাইরে থেকে যা প্রয়োজন হয় না তা স্লাইস এবং সেগমেন্টে আলাদা করে। একটি স্লাইসের ভিতরের অংশগুলিতে অ্যাক্সেস সীমাবদ্ধ, এবং পাবলিক API হল একটি স্লাইস বা অংশ থেকে কার্যকারিতা এবং উপাদানগুলি অ্যাক্সেস করার একমাত্র উপায়৷
উত্তরাধিকারও স্তরগুলির মাধ্যমে অর্জন করা হয়, কারণ উচ্চ স্তরগুলি নিম্ন স্তরগুলিকে পুনরায় ব্যবহার করতে পারে।
আমি বিশ্বাস করি আপনি অনেকবার ক্লাসিক আর্কিটেকচার জুড়ে এসেছেন। বেশিরভাগ লেখক এটির সরলতার কারণে শিক্ষামূলক নিবন্ধ এবং YouTube ভিডিওগুলিতে এটি ব্যবহার করেন। শাস্ত্রীয় স্থাপত্যের জন্য কোন নির্দিষ্ট মান নেই। যাইহোক, প্রায়ই আপনি নিম্নলিখিত বিন্যাস দেখতে পারেন:
ক্লাসিক স্থাপত্যের লক্ষণীয় ত্রুটি রয়েছে। সবচেয়ে বড়টি হল উপাদান এবং মডিউল বিশৃঙ্খলার মধ্যে অন্তর্নিহিত সংযোগের কারণে প্রকল্পটি বজায় রাখা কঠিন হয়ে পড়ে। ক্লাসিক স্থাপত্যের ত্রুটিগুলি সময়ের সাথে আরও স্পষ্ট হয়ে ওঠে। প্রকল্পটি যত বেশি বিকশিত হবে, তত বেশি অ্যাপ্লিকেশন আর্কিটেকচার একটি জটিল জগাখিচুড়িতে পরিণত হবে যা উন্মোচন করা কঠিন।
ক্লাসিক আর্কিটেকচার চলমান রক্ষণাবেক্ষণ বা পোষা প্রকল্প ছাড়াই ছোট প্রকল্পের জন্য উপযুক্ত।
ফিচার-স্লাইসড ডিজাইন, এর ধারণা এবং মানগুলির জন্য ধন্যবাদ, ক্লাসিক আর্কিটেকচারের সমস্যাগুলি প্রতিরোধ করে।
যাইহোক, FSD এর সাথে কাজ করা বিকাশকারীদের বোঝার এবং দক্ষতার স্তর ক্লাসিক আর্কিটেকচারের সাথে কাজ করার চেয়ে বেশি হওয়া উচিত। সাধারণত, 2 বছরের কম অভিজ্ঞতাসম্পন্ন বিকাশকারীরা FSD-এর কথা শোনেননি।
যাইহোক, ফিচার-স্লাইসড ডিজাইনের সাথে কাজ করার সময়, সমস্যাগুলি "পরে" না করে "এখন" সমাধান করা দরকার। কোডের সমস্যা এবং ধারণা থেকে বিচ্যুতি অবিলম্বে স্পষ্ট হয়ে ওঠে
সাধারণ মডুলার আর্কিটেকচারের বেশ কিছু ত্রুটি রয়েছে:
মনে হচ্ছে যে কোনো জটিল বা মাঝারি জটিল প্রকল্পে, সাধারণ মডুলার আর্কিটেকচারের চেয়ে ফিচার-স্লাইসড ডিজাইনকে প্রাধান্য দেওয়া উচিত। এফএসডি অনেক মৌলিক স্থাপত্য সমস্যা সমাধান করে এবং কিছু ত্রুটি রয়েছে।
সরলতা এবং বিকাশের গতির পরিপ্রেক্ষিতে, একটি সাধারণ মডুলার আর্কিটেকচারের FSD এর উপর একটি সুবিধা থাকতে পারে। যদি একটি MVP প্রয়োজন হয় বা একটি স্বল্পস্থায়ী প্রকল্প তৈরি করা হচ্ছে, একটি সাধারণ মডুলার আর্কিটেকচার FSD এর চেয়ে বেশি উপযুক্ত হতে পারে। কিন্তু অন্য কোনো ক্ষেত্রে, একটি বৈশিষ্ট্য-কাটা নকশা পছন্দনীয় দেখায়।
FSD একটি তরুণ স্থাপত্য পদ্ধতি। যাইহোক, এটি ইতিমধ্যে অনেক ব্যাঙ্কিং, ফিনটেক, B2B, ই-কমার্স কোম্পানি এবং অন্যান্যদের দ্বারা ব্যবহার করা হচ্ছে। এখানে কোম্পানিগুলির একটি তালিকা সহ GitHub সমস্যাটির একটি লিঙ্ক রয়েছে: GitHub সমস্যা ।
এই নিবন্ধটি প্রকাশের সময় অফিসিয়াল FSD ডকুমেন্টেশন সহ GitHub সংগ্রহস্থলে 1.1k এর বেশি তারা ছিল। ডকুমেন্টেশন সক্রিয়ভাবে প্রসারিত হচ্ছে, এবং FSD ডেভেলপমেন্ট টিম এবং Telegram এবং Discord-এ সম্প্রদায় 24/7 স্থাপত্য-সম্পর্কিত প্রশ্নে লোকেদের সাহায্য করার জন্য উপলব্ধ।
এই স্থাপত্যের সম্ভাব্যতা অত্যন্ত বিবেচিত, এবং এর ব্যবহার বিশ্বব্যাপী বৃহৎ কোম্পানিগুলির মধ্যে ব্যাপকভাবে ছড়িয়ে পড়েছে। যথাযথ গ্রহণের সাথে, FSD-এর সম্মুখভাগের বিকাশের ক্ষেত্রে প্রভাবশালী স্থাপত্য সমাধান হওয়ার সম্ভাবনা রয়েছে।
ফিচার-স্লাইসড ডিজাইন একটি আকর্ষণীয় এবং মূল্যবান আবিষ্কার যা ফ্রন্টএন্ড ডেভেলপারদের জানা উচিত এবং ব্যবহার করতে সক্ষম হওয়া উচিত। FSD একটি নমনীয়, প্রমিত, এবং মাপযোগ্য আর্কিটেকচার এবং উন্নয়ন সংস্কৃতির সাথে দলগুলিকে প্রদান করতে পারে। যাইহোক, পদ্ধতির ইতিবাচক দিকগুলি ব্যবহার করার জন্য দলের মধ্যে জ্ঞান, সচেতনতা এবং শৃঙ্খলা প্রয়োজন।
এফএসডি অন্যান্য আর্কিটেকচারের মধ্যে তার স্পষ্ট ব্যবসায়িক অভিযোজন, সত্তার সংজ্ঞা, কার্যকরী রচনা এবং অ্যাপ্লিকেশনটির উপাদানগুলির সংমিশ্রণের কারণে আলাদা।
এছাড়াও আপনি স্বাধীনভাবে প্রকল্পে FSD ব্যবহারের উদাহরণ এবং অফিসিয়াল ফিচার-স্লাইসড ডিজাইন ডকুমেন্টেশন অন্বেষণ করতে পারেন:
উদাহরণ। নাইকি স্নিকার এবং জুতার দোকান
এই পোস্টটি দীর্ঘ হতে পারে, তবে আমি আশা করি আপনি নতুন কিছু শিখেছেন। আমি প্রশংসা করি যে আপনি এই পোস্টটি পড়া শেষ করেছেন।
আপনার কোন চিন্তা বা প্রশ্ন থাকলে, একটি মন্তব্য করতে বিনা দ্বিধায়!
এছাড়াও এখানে প্রকাশিত