এক নজরে অপরিহার্য: ক্লিন আর্কিটেকচার, রবার্ট সি. মার্টিন

এটি বই সম্পর্কে ছাপ সম্পর্কে একটি গল্প হবে, এবং কিছু ধারণা এবং জ্ঞান যা এই বইটির জন্য ধন্যবাদ, অধ্যয়ন করা হয়েছে তা বিবেচনা করা হবে।

স্থাপত্য

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

1. আচরণ - ফাংশন এবং কাজ যা প্রোগ্রাম (কম্পোনেন্ট, পরিষেবা) সঞ্চালিত করে।
2. আর্কিটেকচার হল অ্যাপ্লিকেশন পরিবর্তন করার বিষয়ে আরও একটি শব্দ।

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

এবং এই স্থাপত্যটি কীভাবে তৈরি করা যায়, প্রধানমন্ত্রীর কাছ থেকে বা স্টেকহোল্ডারের কাছ থেকে প্রয়োজনীয়তার সামান্য পরিবর্তনের মাধ্যমে কীভাবে মাথাব্যথা থেকে মুক্তি পাওয়া যায়: বইটি এটিই বলবে।

লেখক সম্পর্কে

এই বইটি সম্পর্কে কিছু বলার আগে আমি নিজের সম্পর্কে একটু বলতে চাই।
আমি বর্তমানে ASP .NET CORE এর সাথে সার্ভিস ডেভেলপমেন্টে বিশেষজ্ঞ একজন শক্তিশালী জুনিয়র ডেভেলপার।

আমি এখন এক বছর ধরে একই "গ্যালারী" এ কাজ করছি, এবং আমি একটু মোকাবিলা করছি বলে মনে হচ্ছে

আমি ইতিমধ্যে এই বইটি 2 বার পড়েছি, এবং আমি প্রত্যেককে এটি পড়ার পরামর্শ দিচ্ছি:

• এমবেড সিস্টেমের বিকাশকারী;
• ফ্রন্ট-এন্ড শ্রমিক;
• ব্যাক-এন্ড শ্রমিক;
• এবং এমনকি devops.

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

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

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

বই সম্পর্কে

নির্ভরতা

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

এবং বইটি পড়ার সাথে সাথে আমি দুটি জিনিস শিখেছি:

নির্ভরতা একটি শব্দ যার অর্থ হল কিছু শ্রেণী (উপাদান, পরিষেবা) অন্য কোন শ্রেণীর (উপাদান, পরিষেবা) সম্পর্কে জানে এবং কোড স্তরে এই জ্ঞানটি একটি নির্দিষ্ট নামস্থান আমদানি দ্বারা নির্ধারিত হয় (এখন javaists, sharpists, sishniki আমাকে বুঝবে) . অন্য কথায়: আপনার নামস্থান ডিফল্ট ক্লাস এ সহ ক্লাস এ রয়েছে এবং ক্লাস বি আরেকটি। সুতরাং, যদি Other.Classes ব্যবহার করা হয় ক্লাস A এর সোর্স কোডে উপস্থিত হয়; - এর মানে হল যে ক্লাস A ক্লাস B এর উপর নির্ভর করে।
ডায়াগ্রাম থেকে বোঝার জন্য যে নির্ভরশীল শ্রেণীটি কোথায় এবং কোথায় নয়, তীরের দিকটি দেখুন: 1) তীরটি শ্রেণী A থেকে B শ্রেণীর দিকে নির্দেশ করবে। এর মানে হল যে B শ্রেণীটি এর চেয়ে বেশি স্বাধীন ক্লাস A. এবং ক্লাস A-তে পরিবর্তন, B শ্রেণীতে কোন "ক্ষতি" হবে না

কঠিন

আমার এই বইটি পড়ার একটি প্রধান কারণ ছিল উৎস থেকে SOLID নীতিগুলি ব্যাখ্যা করা, কারণ আঙ্কেল রব এই নীতিগুলি তৈরি করেছিলেন এবং আমরা বলতে পারি যে তাকে ধন্যবাদ আমরা এই নামটি শুনেছি - SOLID।
যারা জানেন না তাদের জন্য, এই নীতিগুলি আপনাকে 5টি নিয়ম অনুসারে আপনার অ্যাপ্লিকেশনগুলি ডিজাইন করার পরামর্শ দেয়:

S - SRP (একক দায়িত্ব নীতি)
O - OCP (খোলা-বন্ধ নীতি)
L - LSP (লিসকভ প্রতিস্থাপন নীতি)
I - ISP (ইন্টারফেস সেগ্রিগেশন নীতি)
D - DIP (নির্ভরতা বিপরীত নীতি)

এই সমস্ত নীতিগুলি ক্লাস এবং অবজেক্টের স্তরে, মডিউল এবং উপাদানগুলির স্তরে এবং লিঙ্কগুলির (পরিষেবা) স্তরে প্রয়োগ করা যেতে পারে।

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

নির্ভরতা ইনভার্সন সম্পর্কে

আমি ডিপেনডেন্সি ইনভার্সন প্রিন্সিপল (যেটি SOLID'a থেকে ডি) এর ব্যাখ্যার প্রতি বিশেষ মনোযোগ দিতে চাই। বইটি পড়ার সময়, আমি বুঝতে পেরেছিলাম যে এটি কেবল একটি নীতি নয়, এটি একটি প্রক্রিয়া এবং একটি সরঞ্জাম যার সাহায্যে আপনি আপনার নির্ভরশীলতার দিক পরিবর্তন করতে পারেন এবং উদাহরণস্বরূপ, ব্যবসায়িক যুক্তি (DOMAIN) স্বাধীন করতে পারেন ডেটা অ্যাক্সেস লেয়ার (DAL) এর বাস্তবায়নের বিবরণ

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

স্থাপত্য সংক্রান্ত সিদ্ধান্ত নেওয়ার বিষয়ে

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

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

উদাহরণস্বরূপ, হঠাৎ করে, আপনি Postgresql-এর পরিবর্তে MongoDb বা সাধারণভাবে ফাইল ব্যবহার করার বা উপহাস করা ডেটা ব্যবহার করার সিদ্ধান্ত নিয়েছেন, যে অপারেশনগুলি মেমরিতে সঞ্চালিত হবে। এবং কিছু শর্তের অধীনে, এটি আপনাকে প্রায় সমস্ত যুক্তি পুনরায় লিখতে বাধ্য করতে পারে।

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

DDD এর রেফারেন্স

DDD - ডোমেন চালিত ডিজাইন - জটিল ব্যবসায়িক যুক্তি সহ পরিষেবাগুলির বিকাশের একটি পদ্ধতি, পরিবর্তনের জন্য সমালোচনামূলক, যার লক্ষ্য সাধারণ রোয়ারদের সাথে প্রকল্প পরিচালনার অবস্থানগুলি (PMs, বিক্রয় ব্যবস্থাপক, ইত্যাদি) বোঝার সর্বোচ্চ লক্ষ্য। অর্থাৎ, যাতে সমস্ত প্রকল্প সদস্যদের মধ্যে একটি সর্বব্যাপী ভাষা থাকে, এবং প্রত্যেকে অন্যকে বুঝতে পারে, এবং যাতে প্রত্যেকে একই ব্যবসার নিয়মের সাথে একই ডোমেনে চিন্তা করে।

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

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

বিমূর্ততা

আঙ্কেল রব আরও কথা বলেন যে কীভাবে বাস্তবায়নের বিবরণ আপনার সিস্টেমের ক্ষতি করতে পারে এবং ভবিষ্যতে ব্যথা ছাড়াই এটিকে বিকশিত হওয়া থেকে বিরত রাখতে পারে।

মনে রাখবেন!
ডাটাবেস একটি বাস্তবায়ন বিবরণ
ক্লায়েন্ট (ওয়েব, মোবাইল, ইত্যাদি) - বাস্তবায়নের বিবরণ
ফ্রেমওয়ার্ক একটি বাস্তবায়ন বিবরণ

এই সব থেকে, আপনাকে যতটা সম্ভব বিমূর্ত করতে হবে এবং নির্ভর না করে, ইন্টারফেস এবং বিমূর্ততা, নির্ভরতা নিয়ম এবং অন্যান্য প্রক্রিয়া সহ উপরে বর্ণিত নির্ভরতা ইনভার্সন ব্যবহার করে

মডিউল নির্মাণের পদ্ধতি

ASP .NET CORE'e-এর পরিষেবাগুলির বিকাশকারী হিসাবে আমি এই বিভাগটি বিশেষভাবে পছন্দ করেছি৷ এখানে তারা রেডিমেড উপাদান থেকে একটি ইউনিফাইড সার্ভিস আর্কিটেকচার তৈরির পদ্ধতি সম্পর্কে কথা বলে।

রবার্ট 4 টি সম্ভাব্য স্তর বিচ্ছেদ স্কিম বর্ণনা করেছেন।

তিনি স্পষ্ট করেছেন কেন 3-স্তর আর্কিটেকচারের এত সাধারণভাবে ব্যবহৃত প্রক্রিয়া: UI (নিয়ন্ত্রক), পরিষেবা (ডোমেন), DAL (ডাটাবেস) অন্যদের তুলনায় বরং খারাপ। আমি খুব বেশি প্রকল্প দেখিনি, তবে প্রতিটিতে, উদাহরণস্বরূপ, একটি মাইক্রো-সার্ভিস, পিছনের প্রান্তে, ঠিক একটি তিন-স্তর আর্কিটেকচার ব্যবহার করা হয়েছে।

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

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

উত্স: www.habr.com