একটি ফ্রন্টএন্ড অ্যাপ্লিকেশনে একটি পরিষ্কার আর্কিটেকচার পরীক্ষা করা - এটি কি অর্থপূর্ণ?

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

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

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

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

এই নিবন্ধে, আমি এই যাত্রা থেকে আমার অভিজ্ঞতা এবং অন্তর্দৃষ্টিগুলি ভাগ করব, কিভাবে ফ্রন্টএন্ডে ক্লিন আর্কিটেকচার সফলভাবে বাস্তবায়ন করা যায় তার একটি বিস্তৃত নির্দেশিকা অফার করব।

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

ফ্রেমওয়ার্ক

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

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

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

এটি পণ্য কোম্পানি বা দীর্ঘমেয়াদী চুক্তির জন্য বিশেষভাবে গুরুত্বপূর্ণ যেগুলি রক্ষণাবেক্ষণ জড়িত, যেখানে পরিবর্তনশীল প্রবণতা এবং প্রযুক্তিগত অগ্রগতিগুলি অবশ্যই অন্তর্ভুক্ত করা উচিত।

ফ্রেমওয়ার্কের মতো বিশদ বিবরণ থেকে স্বাধীন হওয়া, আমরা যে পণ্যটিতে কাজ করছি তার উপর ফোকাস করতে এবং এর জীবনচক্রের সময় উদ্ভূত পরিবর্তনের জন্য প্রস্তুত হতে দেয়।

ভয় পাবেন না; এই নিবন্ধটি এই দ্বিধা একটি উত্তর প্রদান করার লক্ষ্যে.

ফুলস্ট্যাক টিম সহযোগিতা

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

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

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

তাত্ত্বিক ভিত্তি

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

এই বিভাগে, আমরা তিনটি মূল ধারণা উপস্থাপন করব যা আমাদের স্থাপত্য পদ্ধতির ভিত্তি তৈরি করে: সলিড নীতি , ক্লিন আর্কিটেকচার (যা আসলে সলিড নীতি থেকে আসে), এবং পারমাণবিক নকশা । আপনি যদি এই অঞ্চলগুলি সম্পর্কে দৃঢ়ভাবে অনুভব করেন তবে আপনি এই বিভাগটি এড়িয়ে যেতে পারেন।

সলিড নীতি

সলিড একটি সংক্ষিপ্ত রূপ যা পাঁচটি নকশা নীতির প্রতিনিধিত্ব করে যা বিকাশকারীদেরকে স্কেলযোগ্য, রক্ষণাবেক্ষণযোগ্য এবং মডুলার সফ্টওয়্যার তৈরিতে গাইড করে:

• একক দায়বদ্ধতার নীতি (SRP) : এই নীতিটি বলে যে একটি শ্রেণীর পরিবর্তনের শুধুমাত্র একটি কারণ থাকা উচিত, যার অর্থ একটি একক দায়িত্ব থাকা উচিত। এসআরপি মেনে চলার মাধ্যমে, বিকাশকারীরা আরও বেশি মনোযোগী, রক্ষণাবেক্ষণযোগ্য এবং পরীক্ষাযোগ্য কোড তৈরি করতে পারে।

• ওপেন/ক্লোজড প্রিন্সিপল (ওসিপি) : ওসিপি অনুসারে, সফ্টওয়্যার সত্ত্বাগুলি এক্সটেনশনের জন্য উন্মুক্ত হওয়া উচিত কিন্তু পরিবর্তনের জন্য বন্ধ করা উচিত। এর মানে হল যে বিকাশকারীদের বিদ্যমান কোড পরিবর্তন না করে নতুন কার্যকারিতা যোগ করতে সক্ষম হওয়া উচিত, বাগ প্রবর্তনের ঝুঁকি হ্রাস করা।

• লিসকভ সাবস্টিটিউশন প্রিন্সিপল (এলএসপি) : এলএসপি দাবি করে যে একটি প্রাপ্ত শ্রেণীর বস্তুগুলি প্রোগ্রামের সঠিকতাকে প্রভাবিত না করেই বেস ক্লাসের বস্তুগুলিকে প্রতিস্থাপন করতে সক্ষম হওয়া উচিত। এই নীতিটি উত্তরাধিকার এবং পলিমারফিজমের সঠিক ব্যবহারকে উৎসাহিত করে।

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

• ডিপেনডেন্সি ইনভার্সন প্রিন্সিপল (ডিআইপি) : ডিআইপি ডেভেলপারদেরকে কংক্রিট বাস্তবায়নের পরিবর্তে বিমূর্ততার উপর নির্ভর করতে উৎসাহিত করে। এই নীতিটি আরও মডুলার, পরীক্ষাযোগ্য, এবং নমনীয় কোডবেস তৈরি করে।

আপনি যদি এই বিষয়টিকে আরও গভীরভাবে অন্বেষণ করতে চান, যা আমি আপনাকে দৃঢ়ভাবে করতে উত্সাহিত করি, তাহলে কোন সমস্যা নেই। যাইহোক, আপাতত আমি যা উপস্থাপন করেছি তা আরও এগিয়ে যাওয়ার জন্য যথেষ্ট।

এবং এই নিবন্ধের পরিপ্রেক্ষিতে SOLID আমাদের কী দেয়?

ক্লিন আর্কিটেকচার

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

সুতরাং, ক্লিন আর্কিটেকচার একটি নতুন ধারণা নয়; এটি কার্যকরী প্রোগ্রামিং এবং ব্যাকএন্ড উন্নয়ন সহ বিভিন্ন প্রোগ্রামিং দৃষ্টান্তে ব্যাপকভাবে ব্যবহৃত হয়েছে।

লোডাশের মতো লাইব্রেরি এবং অসংখ্য ব্যাকএন্ড ফ্রেমওয়ার্ক এই স্থাপত্য পদ্ধতি গ্রহণ করেছে, যা সলিড নীতির মধ্যে নিহিত।

ক্লিন আর্কিটেকচার উদ্বেগের বিচ্ছেদ এবং একটি অ্যাপ্লিকেশনের মধ্যে স্বাধীন, পরীক্ষাযোগ্য স্তর তৈরির উপর জোর দেয়, যার প্রাথমিক লক্ষ্য সিস্টেমটিকে বোঝা, বজায় রাখা এবং সংশোধন করা সহজ করে তোলা।

স্থাপত্যটি এককেন্দ্রিক বৃত্ত বা স্তরগুলিতে সংগঠিত হয়; প্রতিটিরই স্পষ্ট সীমানা, নির্ভরতা এবং দায়িত্ব রয়েছে:

• সত্তা : এগুলি হল মূল ব্যবসায়িক বস্তু এবং অ্যাপ্লিকেশনের মধ্যে নিয়ম। সত্তা সাধারণত সাধারণ বস্তু যা ডোমেনে প্রয়োজনীয় ধারণা বা ডেটা স্ট্রাকচারের প্রতিনিধিত্ব করে, যেমন ব্যবহারকারী, পণ্য বা অর্ডার।

• কেস ব্যবহার করুন : ইন্টারঅ্যাক্টর নামেও পরিচিত, ইউজ কেস অ্যাপ্লিকেশন-নির্দিষ্ট ব্যবসার নিয়মগুলিকে সংজ্ঞায়িত করে এবং সত্তা এবং বাহ্যিক সিস্টেমের মধ্যে মিথস্ক্রিয়া সাজায়। ব্যবহারের কেসগুলি অ্যাপ্লিকেশনের মূল কার্যকারিতা বাস্তবায়নের জন্য দায়ী এবং বাইরের স্তরগুলির অজ্ঞেয়বাদী হওয়া উচিত।

• ইন্টারফেস অ্যাডাপ্টার : এই উপাদানগুলি ভিতরের এবং বাইরের স্তরগুলির মধ্যে একটি সেতু হিসাবে কাজ করে, ব্যবহারের ক্ষেত্রে এবং বহিরাগত সিস্টেম বিন্যাসের মধ্যে ডেটা রূপান্তর করে। ইন্টারফেস অ্যাডাপ্টারগুলির মধ্যে রয়েছে সংগ্রহস্থল, উপস্থাপক এবং কন্ট্রোলার, যা অ্যাপ্লিকেশনটিকে ডেটাবেস, বহিরাগত API এবং UI ফ্রেমওয়ার্কগুলির সাথে যোগাযোগ করতে সক্ষম করে।

• ফ্রেমওয়ার্ক এবং ড্রাইভার : এই সবচেয়ে বাইরের স্তরটি বহিরাগত সিস্টেমগুলিকে অন্তর্ভুক্ত করে, যেমন ডাটাবেস, UI ফ্রেমওয়ার্ক এবং তৃতীয় পক্ষের লাইব্রেরি। ফ্রেমওয়ার্ক এবং ড্রাইভারগুলি অ্যাপ্লিকেশন চালানোর জন্য প্রয়োজনীয় অবকাঠামো প্রদানের জন্য এবং অভ্যন্তরীণ স্তরগুলিতে সংজ্ঞায়িত ইন্টারফেসগুলি বাস্তবায়নের জন্য দায়ী৷

ক্লিন আর্কিটেকচার বাইরের স্তর থেকে অভ্যন্তরীণ স্তরে নির্ভরতার প্রবাহকে প্রচার করে, নিশ্চিত করে যে মূল ব্যবসায়িক যুক্তিটি ব্যবহৃত নির্দিষ্ট প্রযুক্তি বা কাঠামোর থেকে স্বাধীন থাকে।

এটি একটি নমনীয়, রক্ষণাবেক্ষণযোগ্য এবং পরীক্ষাযোগ্য কোডবেস তৈরি করে যা পরিবর্তনের প্রয়োজনীয়তা বা প্রযুক্তি স্ট্যাকের সাথে সহজেই খাপ খাইয়ে নিতে পারে।

পারমাণবিক নকশা

পারমাণবিক ডিজাইন এমন একটি পদ্ধতি যা UI উপাদানগুলিকে তাদের সবচেয়ে মৌলিক উপাদানগুলির মধ্যে ভাঙ্গিয়ে এবং তারপরে তাদের আরও জটিল কাঠামোতে পুনরায় একত্রিত করে সংগঠিত করে। ব্র্যাড ফ্রস্ট 2008 সালে "পরমাণু ডিজাইন পদ্ধতি" শিরোনামের একটি নিবন্ধে প্রথম ধারণাটি চালু করেছিলেন।

এখানে পারমাণবিক ডিজাইনের ধারণা দেখানো একটি গ্রাফিক রয়েছে:

এটি পাঁচটি স্বতন্ত্র স্তর নিয়ে গঠিত:

• পরমাণু : ইন্টারফেসের ক্ষুদ্রতম, অবিভাজ্য একক, যেমন বোতাম, ইনপুট এবং লেবেল।

• অণু : পরমাণুর গ্রুপ যা একসাথে কাজ করে, ফর্ম বা নেভিগেশন বারের মতো আরও জটিল UI উপাদান গঠন করে।

• জীব : অণু এবং পরমাণুর সংমিশ্রণ যা ইন্টারফেসের স্বতন্ত্র বিভাগ তৈরি করে, যেমন হেডার বা ফুটার।

• টেমপ্লেট : জীব, অণু এবং পরমাণু স্থাপনের জন্য একটি কঙ্কাল প্রদান করে একটি পৃষ্ঠার বিন্যাস এবং গঠন উপস্থাপন করুন।

• পৃষ্ঠা : চূড়ান্ত ইন্টারফেস প্রদর্শন করে প্রকৃত বিষয়বস্তু দিয়ে পূর্ণ টেমপ্লেটের উদাহরণ।

পারমাণবিক ডিজাইনকে আলিঙ্গন করে, বিকাশকারীরা বিভিন্ন সুবিধা পেতে পারে, যেমন মডুলারিটি, পুনঃব্যবহারযোগ্যতা এবং UI উপাদানগুলির জন্য একটি স্পষ্ট কাঠামো, কারণ এর জন্য আমাদের ডিজাইন সিস্টেম পদ্ধতি অনুসরণ করতে হবে, কিন্তু এটি এই নিবন্ধের বিষয় নয়, তাই এগিয়ে যান।

কেস স্টাডি: NotionLingo

ফ্রন্টএন্ড ডেভেলপমেন্টের জন্য ক্লিন আর্কিটেকচারের উপর একটি সুপরিচিত দৃষ্টিভঙ্গি তৈরি করার জন্য, আমি একটি অ্যাপ্লিকেশন তৈরি করার জন্য একটি যাত্রা শুরু করেছি। ছয় মাসের মধ্যে, আমি এই প্রকল্পে কাজ করার সময় মূল্যবান অন্তর্দৃষ্টি এবং অভিজ্ঞতা অর্জন করেছি।

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

আপনি এখানে সংগ্রহস্থল পরিদর্শন করে চূড়ান্ত ফলাফল অন্বেষণ করতে পারেন https://github.com/Levofron/NotionLingo .

ক্লিন আর্কিটেকচার বাস্তবায়ন

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

• ডোমেন স্তর : আমাদের অ্যাপ্লিকেশনের মূল, ব্যবসা-সম্পর্কিত মডেল, ব্যবহারের কেস এবং অপারেশনগুলি অন্তর্ভুক্ত করে।

• API স্তর : ব্রাউজার API এর সাথে ইন্টারঅ্যাক্ট করার জন্য দায়ী।

• সংগ্রহস্থল স্তর : ডোমেন এবং API স্তরগুলির মধ্যে একটি সেতু হিসাবে কাজ করে, আমাদের ডোমেনের প্রকারগুলিতে API প্রকারগুলিকে ম্যাপ করার জন্য একটি স্থান প্রদান করে৷

• UI স্তর : ব্যবহারকারী ইন্টারফেস গঠন করে, আমাদের উপাদানগুলিকে সামঞ্জস্য করে।

এই সাধারণতাগুলি বোঝার মাধ্যমে, আমরা ক্লিন আর্কিটেকচারের মৌলিক কাঠামোর প্রশংসা করতে পারি এবং এটিকে আমাদের নির্দিষ্ট প্রয়োজনের সাথে মানিয়ে নিতে পারি।

ডোমেইন

আমাদের আবেদনের মূল অংশে রয়েছে:

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

  
  

  মূলত, কেসগুলি ব্যবসায়িক দৃষ্টিকোণ থেকে অ্যাপ্লিকেশনের কাজ এবং প্রক্রিয়াগুলি পরিচালনা করে, নিশ্চিত করে যে সিস্টেমটি পছন্দসই উদ্দেশ্য অনুসারে কাজ করে।

• মডেল : মডেলগুলি অ্যাপ্লিকেশনের মধ্যে ব্যবসায়িক সত্তার প্রতিনিধিত্ব করে। এগুলি টাইপস্ক্রিপ্ট ইন্টারফেস ব্যবহার করে সংজ্ঞায়িত করা যেতে পারে, নিশ্চিত করে যে তারা প্রয়োজন এবং ব্যবসার প্রয়োজনীয়তার সাথে সারিবদ্ধ।

  
  

  উদাহরণ স্বরূপ, যদি কোন ব্যবহারের ক্ষেত্রে Notion থেকে শব্দের একটি তালিকা আনা জড়িত থাকে, তাহলে উপযুক্ত ব্যবসায়িক নিয়ম ও সীমাবদ্ধতা মেনে সেই তালিকার ডেটা কাঠামো সঠিকভাবে বর্ণনা করার জন্য আপনাকে একটি মডেলের প্রয়োজন হবে।

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

  
  

  অপারেশনগুলি ডোমেন-নির্দিষ্ট যুক্তিকে এনক্যাপসুলেট করার জন্য দরকারী যা অ্যাপ্লিকেশনের মধ্যে বিভিন্ন প্রসঙ্গে ভাগ করা এবং ব্যবহার করা যেতে পারে।

• সংগ্রহস্থল ইন্টারফেস : ব্যবহারের ক্ষেত্রে ডেটা অ্যাক্সেস করার জন্য একটি উপায় প্রয়োজন। ডিপেন্ডেন্সি ইনভার্সন প্রিন্সিপল অনুযায়ী, ডোমেইন লেয়ার অন্য কোন লেয়ারের উপর নির্ভর করবে না (যদিও অন্য লেয়ারগুলো এর উপর নির্ভর করে); সুতরাং, এই স্তরটি সংগ্রহস্থলগুলির জন্য ইন্টারফেসগুলিকে সংজ্ঞায়িত করে।

  
  

  এটি লক্ষ্য করা গুরুত্বপূর্ণ যে এটি ইন্টারফেসগুলি নির্দিষ্ট করে, বাস্তবায়নের বিবরণ নয়। রিপোজিটরিগুলি নিজেরাই রিপোজিটরি প্যাটার্ন ব্যবহার করে যা প্রকৃত ডেটা উত্সের জন্য অজ্ঞেয় এবং সেই উত্স থেকে ডেটা আনা বা পাঠানোর জন্য যুক্তির উপর জোর দেয়।

  
  

  এটি উল্লেখ করা অত্যন্ত গুরুত্বপূর্ণ যে একটি একক সংগ্রহস্থল একাধিক API প্রয়োগ করতে পারে এবং একটি একক ব্যবহারের ক্ষেত্রে একাধিক সংগ্রহস্থল ব্যবহার করতে পারে।

API

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

এর মধ্যে রয়েছে REST, স্থানীয় স্টোরেজ, IndexedDB, স্পিচ সংশ্লেষণ এবং আরও অনেক কিছুর জন্য APIs।

এটা মনে রাখা গুরুত্বপূর্ণ যে আপনি যদি OpenAPI প্রকার এবং HTTP ক্লায়েন্ট তৈরি করতে চান, API স্তরটি তাদের রাখার জন্য আদর্শ জায়গা। এই স্তরের মধ্যে, আমাদের আছে:

• API অ্যাডাপ্টার : API অ্যাডাপ্টার হল আমাদের অ্যাপ্লিকেশনে ব্যবহৃত ব্রাউজার APIগুলির জন্য একটি বিশেষ অ্যাডাপ্টার৷ এই উপাদানটি অ্যাপের মেমরি বা আপনি ব্যবহার করতে চান এমন অন্য কোনও ডেটা উত্সের সাথে REST কল এবং যোগাযোগ পরিচালনা করে৷

  
  

  এমনকি আপনি চাইলে আপনার নিজস্ব অবজেক্ট স্টোরেজ সিস্টেম তৈরি এবং প্রয়োগ করতে পারেন। একটি ডেডিকেটেড এপিআই অ্যাডাপ্টার থাকার মাধ্যমে, আপনি বিভিন্ন ডেটা উত্সের সাথে ইন্টারঅ্যাক্ট করার জন্য একটি সামঞ্জস্যপূর্ণ ইন্টারফেস বজায় রাখতে পারেন, প্রয়োজন অনুসারে সেগুলিকে আপডেট করা বা পরিবর্তন করা সহজ করে তোলে।

• প্রকার : এটি আপনার API এর সাথে সম্পর্কিত সকল প্রকারের জন্য একটি জায়গা। এই প্রকারগুলি সরাসরি ডোমেনের সাথে সম্পর্কিত নয় কিন্তু API থেকে প্রাপ্ত কাঁচা প্রতিক্রিয়াগুলির বর্ণনা হিসাবে পরিবেশন করে৷ পরবর্তী স্তরে, এই ধরনের সঠিক ম্যাপিং এবং প্রক্রিয়াকরণের জন্য অপরিহার্য হবে।

ভান্ডার

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

আপনি যদি স্থানীয় স্টোরেজের সাথে স্পিচ সংশ্লেষণ API একত্রিত করতে চান, উদাহরণস্বরূপ, এটি করার জন্য এটি উপযুক্ত জায়গা। এই স্তরটি রয়েছে:

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

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

অ্যাডাপ্টার

অ্যাডাপ্টার স্তরটি এই স্তরগুলির মধ্যে মিথস্ক্রিয়াগুলি অর্কেস্ট্রেট করার জন্য এবং তাদের একসাথে বাঁধার জন্য দায়ী। এই স্তরটিতে শুধুমাত্র এর জন্য দায়ী মডিউল রয়েছে:

• নির্ভরতা ইনজেকশন : অ্যাডাপ্টার স্তর API, সংগ্রহস্থল এবং ডোমেন স্তরগুলির মধ্যে নির্ভরতা পরিচালনা করে। নির্ভরতা ইনজেকশন পরিচালনা করে, অ্যাডাপ্টার স্তর উদ্বেগের একটি পরিষ্কার বিচ্ছেদ নিশ্চিত করে এবং দক্ষ কোড পুনঃব্যবহারযোগ্যতা প্রচার করে।

• মডিউল অর্গানাইজেশন : অ্যাডাপ্টার লেয়ার অ্যাপ্লিকেশনটিকে তাদের কার্যকারিতার উপর ভিত্তি করে মডিউলে সংগঠিত করে (যেমন, স্থানীয় স্টোরেজ, আরইএসটি, স্পিচ সংশ্লেষণ, সুপাবেস)। প্রতিটি মডিউল একটি নির্দিষ্ট কার্যকারিতা অন্তর্ভুক্ত করে, যা অ্যাপ্লিকেশনের জন্য একটি পরিষ্কার এবং মডুলার কাঠামো প্রদান করে।

• বিল্ডিং অ্যাকশন : অ্যাডাপ্টার লেয়ার ডোমেন লেয়ার থেকে উপযুক্ত রিপোজিটরির সাথে ইউজ কেস একত্রিত করে অ্যাকশন তৈরি করে। এই ক্রিয়াগুলি অন্তর্নিহিত স্তরগুলির সাথে ইন্টারঅ্যাক্ট করার জন্য অ্যাপ্লিকেশনটির প্রবেশ পয়েন্ট হিসাবে কাজ করে।

উপস্থাপনা

উপস্থাপনা স্তরটি ব্যবহারকারীর ইন্টারফেস (UI) রেন্ডার করার এবং অ্যাপ্লিকেশনটির সাথে ব্যবহারকারীর মিথস্ক্রিয়া পরিচালনা করার দায়িত্বে রয়েছে। এটি একটি কার্যকরী এবং ইন্টারেক্টিভ UI তৈরি করতে অ্যাডাপ্টার, ডোমেন এবং ভাগ করা স্তরগুলিকে ব্যবহার করে৷

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

শেয়ার করা হয়েছে

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

সাধারণ উপাদানগুলি কীভাবে সম্পূর্ণ অ্যাপ্লিকেশন জুড়ে পরিচালিত এবং ভাগ করা হয় তা বোঝার জন্য এটি উল্লেখ করার মতো।

প্রতিটি স্তরের জন্য পরীক্ষার কৌশল

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

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

• API স্তর : ইন্টিগ্রেশন পরীক্ষা ব্যবহার করে API স্তর পরীক্ষা করুন। এই পরীক্ষাগুলি নিশ্চিত করার উপর ফোকাস করা উচিত যে API সঠিকভাবে বাহ্যিক পরিষেবাগুলির সাথে ইন্টারঅ্যাক্ট করে এবং প্রতিক্রিয়াগুলি সঠিকভাবে ফর্ম্যাট করা হয়েছে৷ স্বয়ংক্রিয় পরীক্ষার কাঠামোর মতো সরঞ্জামগুলি ব্যবহার করুন, যেমন জেস্ট, API কলগুলিকে অনুকরণ করতে এবং প্রতিক্রিয়াগুলিকে যাচাই করতে৷

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

• অ্যাডাপ্টার স্তর : ইউনিট পরীক্ষা অ্যাডাপ্টার স্তর পরীক্ষা করার জন্য উপযুক্ত। এই পরীক্ষাগুলি নিশ্চিত করা উচিত যে অ্যাডাপ্টারগুলি সঠিকভাবে নির্ভরতা ইনজেক্ট করে এবং স্তরগুলির মধ্যে ডেটা রূপান্তর পরিচালনা করে। নির্ভরতাকে উপহাস করা, যেমন API বা সংগ্রহস্থল স্তর, পরীক্ষার সময় অ্যাডাপ্টার স্তরকে বিচ্ছিন্ন করতে সহায়তা করতে পারে।

আর্কিটেকচারের প্রতিটি স্তরের জন্য একটি ব্যাপক পরীক্ষার কৌশল প্রয়োগ করে, আপনি বিকাশের সময় বাগগুলি প্রবর্তনের সম্ভাবনা হ্রাস করার সাথে সাথে আপনার অ্যাপ্লিকেশনটির নির্ভরযোগ্যতা, সঠিকতা এবং রক্ষণাবেক্ষণযোগ্যতা নিশ্চিত করতে পারেন।

যাইহোক, যদি আপনি একটি ছোট অ্যাপ্লিকেশন তৈরি করছেন, অ্যাডাপ্টার স্তরে ইন্টিগ্রেশন পরীক্ষাগুলি যথেষ্ট হওয়া উচিত।

আসুন কিছু কোড করি

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

মনে রাখবেন যে আমি এখানে শুধুমাত্র একটি সাধারণ উদাহরণ উপস্থাপন করব; যাইহোক, আপনি যদি আরো বিস্তারিত উদাহরণে আগ্রহী হন, তাহলে নির্দ্বিধায় এই নিবন্ধের শুরুতে উল্লিখিত আমার GitHub সংগ্রহস্থলটি অন্বেষণ করুন।

"বাস্তব জীবনে" ক্লিন আর্কিটেকচার সত্যিই বড়, এন্টারপ্রাইজ-স্তরের অ্যাপ্লিকেশনগুলিতে জ্বলজ্বল করে, যেখানে এটি ছোট প্রকল্পগুলির জন্য অতিরিক্ত কাজ হতে পারে। যে বলে, চলুন পয়েন্ট পেতে.

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

একটি ব্যবসায়িক দৃষ্টিকোণ থেকে, এই শেষ পয়েন্টটি "শব্দ খুঁজুন" দৃশ্যের জন্য অত্যন্ত গুরুত্বপূর্ণ, যা ব্যবহারকারীদের একটি নির্দিষ্ট শব্দ অনুসন্ধান করতে দেয়। একবার ব্যবহারকারী শব্দটি খুঁজে পেলে এবং লগ ইন করলে, তারা তাদের ধারণা ডেটাবেসে ওয়েব-স্ক্র্যাপ করা তথ্য যোগ করতে পারে।

ফোল্ডার স্ট্রাকচার

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

 client ├── adapter ├── api ├── domain ├── presentation ├── repository └── shared

ক্লায়েন্ট ডিরেক্টরিটি অনেক প্রকল্পে "src" ফোল্ডারের অনুরূপ উদ্দেশ্যে কাজ করে। এই নির্দিষ্ট Next.js প্রোজেক্টে, আমি ফ্রন্টএন্ড ফোল্ডারটিকে "ক্লায়েন্ট" এবং ব্যাকএন্ড ফোল্ডারটিকে "সার্ভার" হিসাবে নামকরণের নিয়ম গ্রহণ করেছি।

এই পদ্ধতিটি অ্যাপ্লিকেশনের দুটি প্রধান উপাদানগুলির মধ্যে একটি স্পষ্ট পার্থক্য করার অনুমতি দেয়।

সাবডিরেক্টরি

আপনার প্রকল্পের জন্য সঠিক ফোল্ডার কাঠামো নির্বাচন করা প্রকৃতপক্ষে একটি গুরুত্বপূর্ণ সিদ্ধান্ত যা উন্নয়ন প্রক্রিয়ার প্রথম দিকে করা উচিত। সংস্থানগুলি সংগঠিত করার ক্ষেত্রে বিভিন্ন বিকাশকারীদের নিজস্ব পছন্দ এবং পদ্ধতি রয়েছে।

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

মূল বিষয় হল এমন একটি কাঠামো বেছে নেওয়া যা আপনার প্রকল্পের নির্দিষ্ট চাহিদা এবং স্কেলের সাথে সবচেয়ে উপযুক্ত এবং সম্পদের একটি পরিষ্কার এবং রক্ষণাবেক্ষণযোগ্য সংগঠন বজায় রেখে।

আমি তৃতীয় গোষ্ঠীতে আছি, তাই আমার গঠনটি এইরকম দেখাচ্ছে:

 client ├── adapter │ ├── local-storage │ ├── rest │ ├── speech-synthesis │ └── supabase ├── api │ ├── local-storage │ ├── rest │ ├── speech-synthesis │ └── supabase ├── domain │ ├── local-storage │ ├── rest │ ├── speech-synthesis │ ├── supabase └── repository ├── local-storage ├── rest ├── speech-synthesis └── supabase

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

ডোমেন সংজ্ঞা

আমাদের প্রয়োজনীয়তা বিবেচনা করা যাক. একজন ব্যবহারকারী হিসাবে, আমি তাদের অর্থ এবং উদাহরণ সহ পরামর্শগুলির একটি তালিকা পেতে চাই৷ অতএব, একটি একক অভিধান পরামর্শ নিম্নরূপ মডেল করা যেতে পারে:

 interface DictionarySuggestion { example: string; meaning: string; }

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

ফলস্বরূপ, আমাদের একটি ইন্টারফেস সংজ্ঞায়িত করতে হবে যাতে অভিধানের পরামর্শ এবং শব্দ সংশোধনের একটি তালিকা অন্তর্ভুক্ত থাকে। চূড়ান্ত ইন্টারফেস এই মত দেখায়:

 export interface DictionarySuggestions { suggestions: DictionarySuggestion[]; word: string; }

আমরা এই ইন্টারফেসটি রপ্তানি করছি, তাই export কীওয়ার্ড অন্তর্ভুক্ত করা হয়েছে।

সংগ্রহস্থল ইন্টারফেস

আমাদের মডেল আছে, এবং এখন এটি ব্যবহার করার সময়।

 import { DictionarySuggestions } from './rest.models'; export interface RestRepository { getDictionarySuggestions: (word: string) => Promise<DictionarySuggestions | null>; }

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

অনুগ্রহ করে মনে রাখবেন যে সংগ্রহস্থল সর্বদা ডোমেন মডেল বিন্যাসে ডেটা প্রদান করে।

ব্যবহারের ক্ষেত্রে

এখন, আমাদের ব্যবসার নিয়মকে একটি ব্যবহারের ক্ষেত্রে সংজ্ঞায়িত করা যাক। কোড এই মত দেখায়:

 export type GetDictionarySuggestionsUseCaseUseCase = UseCaseWithSingleParamAndPromiseResult< string, DictionarySuggestions | null >; export const getDictionarySuggestionsUseCase = ( restRepository: RestRepository, ): GetDictionarySuggestionsUseCaseUseCase => ({ execute: (word) => restRepository.getDictionarySuggestions(word), });

উল্লেখ্য প্রথম জিনিস ব্যবহার ক্ষেত্রে সংজ্ঞায়িত করতে ব্যবহৃত সাধারণ ধরনের তালিকা. এটি অর্জন করতে, আমি ডোমেন ডিরেক্টরিতে একটি use-cases.types.ts ফাইল তৈরি করেছি:

 domain ├── local-storage ├── rest ├── speech-synthesis ├── supabase └── use-cases.types.ts

এটি আমাকে আমার সাবডিরেক্টরিগুলির মধ্যে ব্যবহারের ক্ষেত্রে সহজে প্রকারগুলি ভাগ করতে দেয়। UseCaseWithSingleParamAndPromiseResult এর সংজ্ঞা এইরকম দেখায়:

 export interface UseCaseWithSingleParamAndPromiseResult<TParam, TResult> { execute: (param: TParam) => Promise<TResult>; }

এই পদ্ধতিটি ডোমেন স্তর জুড়ে ব্যবহারের কেস প্রকারের ধারাবাহিকতা এবং পুনঃব্যবহারযোগ্যতা বজায় রাখতে সহায়তা করে।

আপনি ভাবছেন কেন আমাদের execute ফাংশন দরকার। এখানে, আমাদের একটি কারখানা আছে যা প্রকৃত ব্যবহারের ক্ষেত্রে ফিরিয়ে দেয়।

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

ফ্যাক্টরি প্যাটার্ন এবং execute ফাংশন ব্যবহার করে, আমরা রিপোজিটরির ইমপ্লিমেন্টেশন ডিটেইলসকে ইউজ কেস কোড থেকে আলাদা রাখতে পারি, যা অ্যাপ্লিকেশানের মডুলারিটি এবং রক্ষণাবেক্ষণযোগ্যতা উন্নত করে।

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

API সংজ্ঞা

প্রথমত, আমাদের ইন্টারফেস সংজ্ঞায়িত করা যাক:

 export interface RestApi { getDictionarySuggestions: (word: string) => Promise<AxiosResponse<DictionarySuggestions>>; }

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

এটা মনে রাখা গুরুত্বপূর্ণ যে আমাদের API কাঁচা ডেটা ফেরত দেয়, তাই আমরা সম্পূর্ণ AxiosResponse<DictionarySuggestions> ফেরত দিই। এটি করার মাধ্যমে, আমরা API এবং ডোমেন স্তরগুলির মধ্যে একটি স্পষ্ট বিচ্ছেদ বজায় রাখি, যা ডেটা পরিচালনা এবং রূপান্তরের ক্ষেত্রে আরও নমনীয়তার অনুমতি দেয়।

এই API এর বাস্তবায়ন এই মত দেখায়:

 export const getRestApi = (axiosInstance: AxiosInstance): RestApi => ({ getDictionarySuggestions: async (word: string) => { const encodedCurrentDate = encodeURIComponent(word); const response = await axiosInstance.get( `${RestEndpoints.GET_DICTIONARY_SUGGESTIONS}?word=${encodedCurrentDate}`, ); return response; } });

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

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

সংগ্রহস্থল বাস্তবায়ন

যেহেতু আমাদের ইন্টারফেস ইতিমধ্যেই ডোমেন দ্বারা সংজ্ঞায়িত করা হয়েছে, তাই আমাদের যা করতে হবে তা হল আমাদের সংগ্রহস্থল বাস্তবায়ন করা। সুতরাং, চূড়ান্ত বাস্তবায়ন এই মত দেখায়:

 export const getRestRepository = (restApi: RestApi): RestRepository => ({ getDictionarySuggestions: async (word) => { const { data } = await restApi.getDictionarySuggestions(word); if (!data?.suggestions?.length) { return null; } return formatDictionarySuggestions(data); } });

উল্লেখ করার জন্য একটি গুরুত্বপূর্ণ দিক হল API এর সাথে সম্পর্কিত। আমাদের getRestRepository আমাদের পূর্বে সংজ্ঞায়িত restApi পাস করতে দেয়। এটি সুবিধাজনক কারণ, যেমন আগে উল্লেখ করা হয়েছে, এটি সহজ পরীক্ষার জন্য অনুমতি দেয়। আমরা সংক্ষেপে formatDictionarySuggestions পরীক্ষা করতে পারি:

 export const formatDictionarySuggestions = ({ suggestions, word, }: DictionarySuggestions): DictionarySuggestions => { const cleanedWord = cleanUpString(word); const cleanedSuggestions = suggestions.map((_suggestion) => { const cleanedMeaning = cleanUpString(_suggestion.meaning); const cleanedExample = cleanUpString(_suggestion.example); return { meaning: cleanedMeaning, example: cleanedExample, }; }); return { word: cleanedWord, suggestions: cleanedSuggestions, }; };

এই ক্রিয়াকলাপটি আমাদের ডোমেন DictionarySuggestions মডেলটিকে একটি আর্গুমেন্ট হিসাবে গ্রহণ করে এবং একটি স্ট্রিং ক্লিনআপ করে, যার অর্থ অপ্রয়োজনীয় স্থান, লাইন ব্রেক, ট্যাব এবং ক্যাপিটালাইজেশন অপসারণ করা। এটা বেশ সোজা, কোন লুকানো জটিলতা ছাড়া.

উল্লেখ্য একটি গুরুত্বপূর্ণ বিষয় হল যে এই মুহুর্তে আপনাকে আপনার API বাস্তবায়ন সম্পর্কে চিন্তা করতে হবে না। একটি অনুস্মারক হিসাবে, সংগ্রহস্থল সর্বদা ডোমেন মডেলের ডেটা ফেরত দেয়! এটি অন্যথায় হতে পারে না কারণ এটি করা নির্ভরতা বিপরীত নীতি ভঙ্গ করবে।

এবং আপাতত, আমাদের ডোমেইন স্তর এর বাইরে সংজ্ঞায়িত কিছুর উপর নির্ভর করে না।

অ্যাডাপ্টার - আসুন একসাথে এই সব রাখুন

এই মুহুর্তে, সবকিছু বাস্তবায়ন করা উচিত এবং নির্ভরতা ইনজেকশনের জন্য প্রস্তুত হওয়া উচিত। এখানে বাকি মডিউলের চূড়ান্ত বাস্তবায়ন:

 import { getRestRepository } from '@repository/rest/rest.repository'; import { getRestApi } from '@api/rest/rest.api'; import { getDictionarySuggestionsUseCase } from '@domain/rest/rest.use-cases'; import { axiosInstance } from '@shared/axios.instance'; const restApi = getRestApi(axiosInstance); const restRepository = getRestRepository(restApi); export const restModule = { getDictionarySuggestions: getDictionarySuggestionsUseCase(restRepository).execute, };

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

পরীক্ষার ক্ষেত্রে, এই আর্কিটেকচারে পরীক্ষাগুলি কীভাবে প্রয়োগ করা হয় এবং সংগঠিত হয় তা বোঝার জন্য সংগ্রহস্থলটি পরীক্ষা করা একটি দুর্দান্ত উপায়।

ক্লিন আর্কিটেকচারে একটি দৃঢ় ভিত্তি সহ, আপনি বিস্তৃত পরীক্ষা লিখতে পারেন যা বিভিন্ন পরিস্থিতিতে কভার করে, আপনার অ্যাপ্লিকেশনটিকে আরও শক্তিশালী এবং নির্ভরযোগ্য করে তোলে।

যেমন প্রদর্শিত হয়েছে, ক্লিন আর্কিটেকচার নীতিগুলি অনুসরণ করা এবং উদ্বেগগুলিকে আলাদা করা একটি রক্ষণাবেক্ষণযোগ্য, মাপযোগ্য এবং পরীক্ষাযোগ্য প্রয়োগ কাঠামোর দিকে নিয়ে যায়।

এই পদ্ধতিটি শেষ পর্যন্ত আপনার অ্যাপ্লিকেশনের দীর্ঘমেয়াদী সাফল্য নিশ্চিত করে নতুন বৈশিষ্ট্য, রিফ্যাক্টর কোড এবং একটি প্রকল্পে একটি দলের সাথে কাজ করা সহজ করে তোলে।

উপস্থাপনা

উদাহরণ অ্যাপ্লিকেশনে, উপস্থাপনা স্তরের জন্য প্রতিক্রিয়া ব্যবহার করা হয়। অ্যাডাপ্টার ডিরেক্টরিতে, hooks.ts নামে একটি অতিরিক্ত ফাইল রয়েছে যা বাকি মডিউলের সাথে মিথস্ক্রিয়া পরিচালনা করে। এই ফাইলের বিষয়বস্তু নিম্নরূপ:

 import { restModule } from '@adapter/rest/rest.module'; import { useAxios } from '@shared/hooks'; export const useDictionarySuggestions = () => { const { data, error, isLoading, mutate } = useAxios(restModule.getDictionarySuggestions); return { dictionarySuggestions: data, getDictionarySuggestions: mutate, dictionarySuggestionsError: error, isDictionarySuggestionsLoading: isLoading, }; };

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

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

এরপর কি?

প্রথম এবং সর্বাগ্রে, আমি আপনাকে প্রদত্ত GitHub রেপো থেকে কোডে ডুব দিতে এবং এর গঠন অন্বেষণ করতে উত্সাহিত করি।

তুমি আর কি করতে পারো? আকাশ আমাদের সীমানা! এটা সব আপনার নির্দিষ্ট নকশা প্রয়োজন উপর নির্ভর করে. উদাহরণস্বরূপ, আপনি একটি ডেটা স্টোর (Redux, MobX, বা এমনকি কাস্টম কিছু - এটা কোন ব্যাপার না) অন্তর্ভুক্ত করে ডেটা স্তর বাস্তবায়নের কথা বিবেচনা করতে পারেন।

বিকল্পভাবে, আপনি স্তরগুলির মধ্যে বিভিন্ন যোগাযোগের পদ্ধতি নিয়ে পরীক্ষা করতে পারেন, যেমন ব্যাকএন্ডের সাথে অ্যাসিঙ্ক্রোনাস যোগাযোগ পরিচালনা করতে RxJS ব্যবহার করা, যার মধ্যে পোলিং, পুশ বিজ্ঞপ্তি বা সকেট অন্তর্ভুক্ত থাকতে পারে (মূলত, যে কোনও ডেটা উত্সের জন্য প্রস্তুত হওয়া)।

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

এটি করার মাধ্যমে, আপনি একটি নমনীয় এবং রক্ষণাবেক্ষণযোগ্য অ্যাপ্লিকেশন কাঠামো তৈরি করবেন যা বিভিন্ন পরিস্থিতিতে এবং প্রয়োজনীয়তার সাথে খাপ খাইয়ে নিতে পারে।

সারসংক্ষেপ

এই নিবন্ধে, আমরা React ব্যবহার করে নির্মিত একটি ভাষা-শিক্ষার অ্যাপ্লিকেশনের প্রেক্ষাপটে ক্লিন আর্কিটেকচারের ধারণা নিয়ে আলোচনা করেছি।

আমরা একটি স্তরযুক্ত আর্কিটেকচার বজায় রাখার এবং বিপরীত নির্ভরতার নীতি মেনে চলার গুরুত্ব তুলে ধরেছি, পাশাপাশি উদ্বেগগুলিকে আলাদা করার সুবিধাগুলিও তুলে ধরেছি।

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

যাইহোক, এই পদ্ধতির কিছু অপূর্ণতা আছে। কিছু ক্ষেত্রে, একটি কঠোর স্থাপত্য প্যাটার্ন অনুসরণ করলে বয়লারপ্লেট কোড বাড়তে পারে বা প্রকল্পের কাঠামোতে জটিলতা বাড়তে পারে।

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

এই সম্ভাব্য চ্যালেঞ্জ সত্ত্বেও, ক্লিন আর্কিটেকচার প্রয়োগ করা অত্যন্ত উপকারী হতে পারে, বিশেষ করে প্রতিক্রিয়ার প্রসঙ্গে, যেখানে সর্বজনীনভাবে স্বীকৃত স্থাপত্য প্যাটার্ন নেই।

বছরের পর বছর সংগ্রাম করার পরে এটিকে সম্বোধন করার পরিবর্তে একটি প্রকল্পের শুরুতে আপনার স্থাপত্যটি বিবেচনা করা অপরিহার্য।

ক্লিন আর্কিটেকচারের বাস্তব জীবনের উদাহরণ অন্বেষণ করতে, নির্দ্বিধায় আমার সংগ্রহস্থলটি এখানে দেখুন https://github.com/Levofron/NotionLingo . আপনি আমার প্রোফাইলে দেওয়া লিঙ্কগুলির মাধ্যমে সোশ্যাল মিডিয়াতে আমার সাথে সংযোগ করতে পারেন।

বাহ, এটি সম্ভবত আমার লেখা দীর্ঘতম নিবন্ধ। এটা অবিশ্বাস্য মনে হয়!