এই সমস্ত পরিষেবাগুলির সাথে, আমি কীভাবে রক্তশূন্য হতে পারি না?


90

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

নিম্নলিখিত উদ্বেগগুলি উদাহরণ হিসাবে নিন:

অনুমোদন । ডোমেন অবজেক্টটি কি তার অ্যাক্সেস নিয়ন্ত্রণের নিয়মগুলি বজায় রাখার জন্য দায়বদ্ধ হতে পারে (যেমন ক্যানডিট সম্পত্তি হিসাবে) বা অন্য যে কোনও উপাদান / পরিষেবাতে অ্যাক্সেস পরিচালনার জন্য দায়ী করা উচিত, যেমন IAuthorizationService.CanEdit (অবজেক্ট)? নাকি এটি দুজনের সংমিশ্রণ হওয়া উচিত? সম্ভবত ডোমেন অবজেক্টের একটি CanEdit সম্পত্তি রয়েছে যা প্রকৃত কাজটি সম্পাদন করার জন্য একটি অভ্যন্তরীণ IAuthorizationService এ প্রতিনিধিত্ব করে?

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

অবজেক্ট ক্রিয়েশন । ফ্যাক্টরি ক্লাস বনাম কারখানার পদ্ধতি বনাম 'নতুনকরণ' উদাহরণ উপস্থাপন করে। যদি আমরা একটি পৃথক কারখানার শ্রেণি ব্যবহার করি তবে আমরা উত্পাদন যুক্তিকে আলাদা করতে এবং encapsulate করতে সক্ষম হয়েছি কিন্তু কারখানায় আমাদের অবজেক্টের অবস্থা খোলার ব্যয়ে। এটি যদি আমাদের ডোমেন স্তরটি কারখানার দ্বারা ব্যবহৃত অভ্যন্তরীণ কন্সট্রাক্টর এক্সপোজ করে পৃথক সমাবেশে থাকে তবে এটি যদি একাধিক তৈরির নিদর্শন থাকে তবে এটি একটি সমস্যা হয়ে দাঁড়ায় managed এবং, যদি সমস্ত ফ্যাক্টরিটি করছে সঠিক কন্সট্রাক্টরকে কল করছে, কারখানাটি থাকার কী লাভ?

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

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

আমি এই কোথায় যাচ্ছি দেখুন?

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

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

আপনার চিন্তাগুলো?


দুর্দান্ত প্রশ্ন। আপনার কাছে আমার কাছে কোনও উত্তর নেই যেহেতু আমি প্রায় সবসময়ই একই কারণে নকশায় সম্পূর্ণ রক্তাল্পতা শেষ করি - ব্যবহার / গ্রাহ্য / বহির্মুখী পরিষেবাগুলি / থেকে বিভিন্ন প্রসঙ্গ বা বিভিন্ন অ্যাপ্লিকেশনগুলিতে ব্যবহার করি।
hromanko

দুর্দান্ত প্রশ্ন, চাচাবোব, মার্টিনফোলার, এরিসেভান্স এট আল দেখতে চাইবেন on এখন আমার চলে যেতে এবং দীর্ঘ চিন্তা করার জন্য
মার্টিজ ভার্বার্গ

আমি নিজেকে সবসময় অ্যানিমিক মডেল হিসাবে বিকশিত হতে দেখি; এবং তাই আমি এই ঠিক একই জিনিস সঙ্গে সংগ্রাম করছি। দুর্দান্ত প্রশ্ন!
এল-ফোর

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

: এখানে কিছু যখন আচরণগত (অ-ডেটা-কেন্দ্রিক) দৃষ্টিকোণ থেকে ডোমেইন মডেলিং ব্যবহার কৌশল একটি উদাহরণ medium.com/@wrong.about/...
Zapadlo

উত্তর:


66

বেশিরভাগ বিভ্রান্তি কার্যকারিতাটির কাছাকাছি বলে মনে হয় যা ডোমেন মডেলটিতে একেবারেই থাকা উচিত নয়:

  • দৃistence়তা কখনই ডোমেন মডেলটিতে থাকা উচিত নয়। কখনই না. এ কারণেই আপনি বিমূর্ত প্রকারের উপর নির্ভর করে যেমন IRepositoryমডেলটির কোনও অংশে মডেলের একটি আলাদা অংশ পুনরুদ্ধার করার মতো কিছু করা দরকার হয় এবং বাস্তবায়নটি সংযুক্ত করার জন্য নির্ভরতা ইনজেকশন বা কিছু অনুরূপ কৌশল ব্যবহার করা উচিত। সুতরাং রেকর্ড থেকে যে আঘাত।

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

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

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

সুতরাং একবার আপনি এই সমস্ত টারফ, যে কেবল বৈধতা ছেড়ে। এটাই একমাত্র ধরণের কৌশল।

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

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

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

থাম্বের নিয়ম হিসাবে, ডোমেন মডেলটিতে কিছু অন্তর্ভুক্ত কিনা তা বিবেচনা করার সময়, নিজেকে নীচের প্রশ্নটি জিজ্ঞাসা করুন:

"নিখুঁত প্রযুক্তিগত কারণে এই কার্যকারিতাটি কি কখনও পরিবর্তিত হতে পারে?" অন্য কথায়, রিয়েল-ওয়ার্ল্ড ব্যবসা বা ডোমেনে কোনও পর্যবেক্ষণযোগ্য পরিবর্তনের কারণে নয়?

যদি উত্তরটি "হ্যাঁ" হয় তবে তা ডোমেন মডেলের অন্তর্ভুক্ত নয়। এটি ডোমেনের অংশ নয়।

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

যদি আপনি কোনও বিষয়বস্তু না ফেলে সমস্ত জিনিস ছিনিয়ে নেওয়ার পরে, আপনি দেখতে পান যে ডোমেন মডেলটি সত্যই রক্তাল্পতাযুক্ত , তবে এটির জন্য আপনার প্রকল্পের জন্য ডিডিডি কেবল ভুল দৃষ্টান্তই হ'ল এটি একটি খুব ভাল ইঙ্গিত হিসাবে কাজ করবে।

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

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


2
এছাড়াও, @ সোনফফায়ারেট, আপনি যে কোনও সময় আপনার পুরো সুরক্ষা মডেলটি পরিবর্তন করতে চান তা সম্পূর্ণ সম্ভাবনা নয়; ভূমিকা-ভিত্তিক সুরক্ষা প্রায়শই দাবি-বা অধিকার-ভিত্তিক সুরক্ষার পক্ষে বা এমনকি আপনি এমনকি ক্ষেত্র-স্তরের সুরক্ষাও চাইলে অনুপস্থিত। যদি এটি ঘটে থাকে তবে আপনার সম্পূর্ণ ডোমেন মডেলটি পুনরায় কাজ করার চেষ্টা করুন।
অ্যারোনআউট

1
@ সোনফপিরেট: এটি প্রায় মনে হচ্ছে আপনি পুরানো "বিজনেস টায়ার" মডেলটির উপরে এখনও কিছুটা আটকে আছেন যেখানে "মাঝারি স্তর" ছিল যা মূলত ডেটা স্তরের উপর একটি পাতলা ব্যহ্যাবরণ ছিল, বিভিন্ন ব্যবসায়ের নিয়ম এবং সাধারণত সুরক্ষা বিধি বাস্তবায়ন করে । ডোমেন স্তরটি এমনটি নয়। ডোমেন হ'ল অন্য সমস্ত কিছুর উপর নির্ভর করে, এটি বাস্তব-জগতের অবজেক্ট এবং সম্পর্কের প্রতিনিধিত্ব করে যা সিস্টেমটি পরিচালনা করার জন্য বোঝানো হয়েছিল।
অ্যারোনআউট

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

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

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

6

অনুমোদন. ডোমেন অবজেক্টটি এর অ্যাক্সেস নিয়ন্ত্রণের নিয়ম বজায় রাখার জন্য দায়বদ্ধ হতে হবে

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

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

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

ভ্যালিডেশন। উপরের মত একই আলোচনা বৈধতার সাথে সম্পর্কিত।

আমি না বলব, ডোমেনে নয় (বেশিরভাগ)) বৈধতা বিভিন্ন প্রসঙ্গে দেখা যায় এবং বৈধতা সংক্রান্ত নিয়মগুলি প্রায়শই প্রসঙ্গে dif একটি সামগ্রিক দ্বারা ডেটা এনপ্যাপুলেটেড ডেটা বিবেচনা করার সময় খুব কমই বৈধ বা কার্যকর বৈধের পরিপূর্ণ জ্ঞান রয়েছে।

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

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

অবজেক্ট ক্রিয়েশন। ফ্যাক্টরি ক্লাস বনাম কারখানার পদ্ধতি বনাম 'নতুনকরণ' উদাহরণ উপস্থাপন করে।

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

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

অধ্যবসায়। ... কেন আমাদের ডোমেন অবজেক্টে একটি সেভ পদ্ধতি নেই

এটি খুব কমই একটি ভাল ধারণা; আমি মনে করি এটিকে সমর্থন করার জন্য প্রচুর অংশীদারি অভিজ্ঞতা রয়েছে।

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

সম্ভবত আপনার আবেদনের এই অংশটির জন্য কোনও ডোমেন মডেল সঠিক পছন্দ নয়।


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

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

1
সাধারণভাবে, গত কয়েক বছর ধরে, আমি একটি ডোমেন বা ব্যবসায়িক আইনে সবকিছু একীভূত করার চেষ্টা থেকে আরও এবং আরও দূরে সরে এসেছি। আমার অভিজ্ঞতা থেকে মনে হয় যে জিনিসগুলিকে আরও দানাদার এবং কম সংযুক্ত করা দীর্ঘমেয়াদী জয় win সুতরাং যখন এক দৃষ্টিকোণ থেকে এই পদ্ধতিটি ডোমেনের বাইরে ব্যবসায়িক যুক্তি স্থাপন করছে (একটি ডিগ্রীতে), এটি পরে চটপটে পরিবর্তনগুলি সমর্থন করে। এটি একটি ভারসাম্য আঘাত সম্পর্কে।
কোয়ান্টিন-তারকাভিন

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

1
অনুমোদনের বিষয়ে থাকা অবস্থায়, আপনি (উভয়) কীভাবে এটি পরিচালনা করবেন তা দেখার জন্য আমাকে টেবিলে একটি স্পষ্ট উদাহরণ বর্ষণ করতে দিন। আমার আমার ডোমেন অবজেক্টে একটি প্রকাশ অপারেশন রয়েছে যার জন্য ব্যবহারকারীকে প্রকাশকের ভূমিকায় থাকা প্রয়োজন এবং অবজেক্টটি নির্দিষ্ট অবস্থায় রয়েছে। আমি ইউআই-তে প্রকাশিত "বাটন" লুকিয়ে রাখতে বা অক্ষম করতে চাই। আপনি কিভাবে এটি সম্পাদন করবেন?
SonOfPirate

4

ঠিক আছে, এখানে আমার জন্য যায়। আমি এ কথাটি বলার আগেই খালি করব:

  • অকাল অপটিমাইজেশন (এবং এতে ডিজাইন অন্তর্ভুক্ত) প্রায়শই সমস্যা দেখা দিতে পারে।

  • আইএএনএমএফ (আমি মার্টিন ফাউলার নই);)

  • একটি নোংরা ছোট রহস্যটি হ'ল ছোট আকারের প্রকল্পগুলিতে (এমনকি যুক্তিযুক্ত আকারের আকারগুলিও) এটি আপনার পদ্ধতির ধারাবাহিকতা যা গুরুত্বপূর্ণ তা বিবেচনা করবে।

অনুমোদন

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

বৈধতা আমার জন্য বৈধতা অবজেক্টের অংশ, যেহেতু আমি দেখছি এটি বস্তুটি কী তা সংজ্ঞায়িত করে।

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

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

অবজেক্ট ক্রিয়েশন

আমি সাবধানতার সাথে কারখানার ক্লাসগুলি দেখি। xyxFactoryFactoryক্লাস আমি খুব প্রায়ই দেখেছি ;)

আমি কেবল newপ্রয়োজন হিসাবে একটি অবজেক্ট তৈরি করার ঝোঁক রেখেছি , যতক্ষণ না আমি ডিপেন্ডেন্সি ইনজেকশনটি সুনিশ্চিত হয় এমন একটি মামলার দিকে না চলে (এবং যেহেতু আমি টিডিডি পদ্ধতির অনুসরণ করার চেষ্টা করি, এটি প্রায়শই না ঘটে)।

আমার খুশি জাভা বিশ্বে যে ক্রমবর্ধমান গুইস, তবে বসন্তের এখনও এখানে রাজা।

অধ্যবসায়

তাই এটি একটি বিতর্ক যা চেনাশোনা এবং চতুর্দিকে চলে এবং আমি এটি সম্পর্কে সর্বদা দুটি মনেই থাকি।

কেউ কেউ বলে যে আপনি যদি 'বিশুদ্ধ' উপায়ে অবজেক্টের দিকে লক্ষ্য করেন তবে অধ্যবসায় একটি মূল সম্পত্তি নয়, এটি কেবল বাহ্যিক উদ্বেগ।

অন্যরা এমন দৃষ্টিভঙ্গি রাখেন যে আপনার ডোমেন অবজেক্টগুলি স্পষ্টভাবে একটি 'অবিচল-সক্ষম' ইন্টারফেস প্রয়োগ করে (হ্যাঁ আমি জানি আমি এখানে প্রসারিত করছি)। অতএব, তাদের বিভিন্ন save, deleteইত্যাদি পদ্ধতি থাকা ভাল fine এটি ব্যবহারিক পদ্ধতির হিসাবে দেখা হয় এবং অনেকগুলি ওআরএম প্রযুক্তি (আমার খুশির জাভা জগতের জেপিএ) অবজেক্টগুলির সাথে এইভাবে ডিল করে।

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

আছে HTH!


2

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

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


কোনও নির্দিষ্ট প্রয়োজনীয়তার মতো শব্দ - ডেটার পুনরায় ব্যবহার (স্ট্রেস 'ডেটা') কাঠামো - সেই সাধারণ অংশটিকে সাধারণ প্লে ডিটিওতে কমে যায়।
ভিক্টর সার্জিইঙ্কো

অ্যানমিক মডেলগুলি আরও ভাল পুনরায় ব্যবহারের অনুমতি দেয়? আরও একটি ডিটিওর মতো শোনাচ্ছে এবং আমি ব্যক্তিগতভাবে সম্পত্তি সংজ্ঞাগুলি পুনরায় ব্যবহার সম্পর্কে কোনও অভিবাদন করি না। আমি বরং আচরণগুলি পুনরায় ব্যবহার করতে চাই।
অ্যান্ডি

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

@ জপিয়ারসন আমি খুঁজে পেয়েছি যে আচরণগুলি সাধারণত কোনও নির্দিষ্ট ব্যবহারের ক্ষেত্রে নির্দিষ্ট। যদি পুনরায় ব্যবহার করা হয়, তবে এটি অন্য শ্রেণীর অন্তর্গত হবে, তবে গ্রাহকরা এই ক্লাসগুলি ব্যবহার করবেন না, তারা ব্যবহারের ক্ষেত্রে নির্দিষ্টটি ব্যবহার করবে। সুতরাং কোনও পুনঃব্যবহার হ'ল "পর্দার পিছনে", তাই কথা বলতে। অধিকন্তু, মডেলগুলি পুনরায় ব্যবহারের চেষ্টা করা সাধারণত গ্রাহকদের জন্য মডেলগুলিকে ব্যবহার করা আরও শক্ত করে তোলে, তাই আপনি ইউআই স্তরে ভিউ / সম্পাদনা মডেল তৈরি করে শেষ করেন। প্রায়শই এরপরে আপনি সমৃদ্ধ ব্যবহারকারীর অভিজ্ঞতা দিতে উদাহরণস্বরূপ DRY লঙ্ঘন করেন (উদাহরণস্বরূপ, সম্পাদনা মডেলগুলির ডেটাঅ্যানোটেশন)।
অ্যান্ডি

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

2

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

ডিডিডি আর্কিটেকচারে কোনও "ডোমেন মডেল" নেই।

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

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

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

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

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

সুতরাং সম্ভবত কেউ অনুমোদনের প্রসঙ্গে একটি অ-অ্যানিমিক ডোমেন মডেলটিকে বিবেচনা করতে পারে যে জুতার চালানের রৌটিংটি কম ইনভেন্টরি সহ স্টোরগুলিতে বা উপযুক্ত রাউটিং সাইট দর্শকদের উপযুক্ত ল্যান্ডিং পৃষ্ঠায় তারা যে বিজ্ঞাপনটি ক্লিক করেছে তার উপর নির্ভর করে rout

যদি আপনি অ্যানিমিক ডোমেন মডেলগুলির সাথে নিজেকে খুঁজে পান তবে আপনি কোড লিখতে শুরু করার আগে আপনাকে কেবল প্রসঙ্গের ম্যাপিংয়ের জন্য আরও বেশি সময় ব্যয় করতে হবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.