আমি ডোমেন-চালিত ডিজাইনের নীতিগুলি উপলব্ধি করার চেষ্টা করে একটি ছোট অ্যাপ্লিকেশন নিয়ে কাজ করছি। যদি সফল হয় তবে এটি বৃহত্তর প্রকল্পের জন্য পাইলট হতে পারে। আমি "ইমপ্লিমেন্টিং ডোমেন-ড্রাইভড ডিজাইন" বইটি (ভন ভার্নন দ্বারা) অনুসরণ করার চেষ্টা করছি এবং অনুরূপ, সহজ আলোচনা ফোরাম বাস্তবায়নের চেষ্টা করছি। আমি গিথুবে আইডিডিডি নমুনাগুলিও পরীক্ষা করে দেখেছি। আমার ক্ষেত্রে পরিচয় এবং অ্যাক্সেস গ্রহণ করতে আমার কিছু অসুবিধা হয়। আমাকে কিছু পটভূমি তথ্য দিতে দিন:
- আমি (আশাবাদী) ব্যবহারকারী এবং অনুমতিগুলির যুক্তি পৃথক করার পিছনে যুক্তিটি বুঝতে পারি: এটি একটি সমর্থনকারী ডোমেন এবং এটি একটি পৃথক সীমিত প্রসঙ্গ।
- মূল ডোমেনে, কোনও ব্যবহারকারী নেই, কেবল লেখক, মডারেটর ইত্যাদি These এগুলি কোনও পরিষেবা ব্যবহার করে পরিচয় এবং অ্যাক্সেস প্রসঙ্গে পৌঁছে দেওয়া এবং তারপরে প্রাপ্ত ব্যবহারকারী সামগ্রী এবং মডারেটরের অনুবাদ করে তৈরি করা হয় ting
ডোমেন অপারেশনগুলিকে প্যারামিটার হিসাবে সম্পর্কিত ভূমিকার সাথে ডাকা হয়: যেমন:
ModeratePost( ..., moderator);প্রদত্ত মডারেটর উদাহরণটি শূন্য না হলে ডোমেন অবজেক্টের পদ্ধতিটি পরীক্ষা করে (ব্যবহারকারী যদি পরিচয় এবং অ্যাক্সেস প্রসঙ্গে জিজ্ঞাসা করে মডারেটরের ভূমিকা না থাকে তবে মডারেটর উদাহরণটি নাল হবে)।
একটি ক্ষেত্রে, এটি কোনও পোস্ট পরিবর্তন করার আগে একটি অতিরিক্ত চেক করে:
if (forum.IsModeratedby(moderator))
আমার প্রশ্নগুলি হ'ল:
পরবর্তী ক্ষেত্রে সুরক্ষা উদ্বেগগুলি কী আবার মূল ডোমেনের সাথে মিশে যায় না? পূর্বে বইগুলিতে বলা হয়েছে "কাদের সাথে কোন বিষয় পোস্ট করা যেতে পারে, বা কোন শর্তে অনুমোদিত তা অনুমোদিত। একটি ফোরামের জানা দরকার যে কোনও লেখক এখনই এটি করছেন"।
বইটিতে ভূমিকা ভিত্তিক বাস্তবায়ন মোটামুটি সহজবোধ্য: যখন কোনও মডারেটর মূল ডোমেন বর্তমান ব্যবহারকারীকে আইডিকে একটি মডারেটর উদাহরণ বা কোনও লেখকের সাথে রূপান্তরিত করার চেষ্টা করে যখন এটির প্রয়োজন হয়। যদি ব্যবহারকারীর প্রয়োজনীয় ভূমিকা না থাকে তবে পরিষেবাটি যথাযথ উদাহরণ বা একটি নাল দিয়ে প্রতিক্রিয়া জানাবে। তবে, আমি দেখতে পাচ্ছি না কীভাবে আমি এটি আরও জটিল সুরক্ষা মডেলের সাথে মানিয়ে নিতে পারি; আমাদের বর্তমান প্রকল্পটি যা আমি চালাচ্ছি তার গ্রুপ, এসিএল ইত্যাদির চেয়ে জটিল মডেল রয়েছে for
এমনকি খুব বেশি জটিল নয় এমন নিয়মগুলিও যেমন: "একটি পোস্ট কেবল তার মালিক বা একটি সম্পাদক দ্বারা সম্পাদনা করা উচিত", এই পদ্ধতিটি ভেঙে গেছে বলে মনে হচ্ছে, বা কমপক্ষে আমি এটি বাস্তবায়নের সঠিক উপায় দেখতে পাচ্ছি না।
কোনও মালিকের জন্য পরিচয় এবং অ্যাক্সেস প্রসঙ্গটি জিজ্ঞাসা করে দৃষ্টান্তটি যথাযথ মনে হয় না এবং আমি কোর ডোমেনে আরও বেশি সংখ্যক সুরক্ষা-সংক্রান্ত ক্লাস শেষ করব। এছাড়াও, আমি কেবল ইউজারআইডিই নয়, সুরক্ষিত সংস্থার সনাক্তকারী (পোস্ট, ফোরাম ইত্যাদির আইডি) সুরক্ষার প্রসঙ্গে যা সম্ভবত এই বিষয়গুলির যত্ন নেওয়া উচিত নয় (এটি কি সঠিক? )
মূল ডোমেনে অনুমতিগুলি টানতে এবং ডোমেন অবজেক্টগুলির পদ্ধতি বা পরিষেবাগুলিতে সেগুলি পরীক্ষা করে, আমি স্কোয়ার একের সাথে শেষ করব: ডোমেনের সাথে সুরক্ষা উদ্বেগগুলি মিশিয়ে।
আমি কোথাও পড়েছি (এবং আমি এটির সাথে একমত হতে চাই) যে সুরক্ষা এবং অনুমতিগুলি মূল ডোমেন না হলে এই অনুমতি সম্পর্কিত জিনিসগুলি মূল ডোমেনের অংশ হওয়া উচিত নয়। উপরোক্ত মত একটি সাধারণ নিয়ম কি সুরক্ষাটিকে মূল ডোমেনের অংশ হিসাবে ন্যায্যতা দেয়?
HasPermissionToEdit(userId, resourceId)তবে তবে এই কলগুলির সাথে ডোমেন যুক্তিকে দূষিত করা ঠিক মনে করি না। সম্ভবত আমার এটিকে অ্যাপ্লিকেশন পরিষেবা পদ্ধতিতে পরীক্ষা করা উচিত, ডোমেন যুক্তি দেওয়ার আগে?
UserService @AccessControlList[inf3rno]হয়েছিল যা আমি যুক্ত উত্তর দিয়েছি in