ডিডিডি - অ্যানিমিক ডোমেন মডেল কি একটি অ্যান্টিপ্যাটার্ন? আমরা কি সমৃদ্ধ ডোমেন মডেলগুলি ব্যবহার করব? [বন্ধ]


11

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

তবে সাম্প্রতিক বছরগুলিতে দ্বিমত পোষণকারী কণ্ঠস্বর দাবি করেছে যে এটি মোটে কোনও প্রতিষেধক নয় এবং এটি সলিড নীতি অনুসরণ করার উদাহরণ is

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

আমার প্রশ্নগুলি: অ্যানিমিক ডোমেন মডেলটি এখনও একটি অ্যান্টিপ্যাটার্ন হিসাবে বিবেচিত হয়? আমরা কি সব কিছু (ডিডিডি সম্পর্কিত) ভুল করছি? আপনি কি ভাবেন না যে রিচ ডোমেন মডেলগুলি থাকা SOLID নীতিগুলি লঙ্ঘন করে?


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

1
এটি একটি আলোচনা / বিতর্ক ফোরামের জন্য দুর্দান্ত প্রশ্ন হবে; তবে বর্তমানে কোনও অনুমোদিত উত্তর নেই। আমরা কেবলমাত্র আলোচিত নয়, উত্তর দেওয়া যেতে পারে এমন প্রশ্নগুলি পছন্দ করি।
ভয়েসফুউনরেজন

উত্তর:


9

এডিএম বিতরণ পরিষেবাদির যেমন একটি মাইক্রোসার্ভিসেসের সমাধানের জন্য ভাল প্যাটার্ন। এটি আজকের ওয়েব ভিত্তিক ব্যবসায়ের বেশিরভাগ ক্ষেত্রে ফিট করে।

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

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

PurchaseSystemOrder.Purchase()

এবং

CancelSystemOrder.Cancel();

এই বিষয়গুলি কেবলমাত্র বৈশিষ্ট্যগুলির ডেটা স্ট্রাকচারটি ভাগ করবে।

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

এটি অ্যানমিক মডেল, অর্ডার পাওয়া আরও বেশি বোঝার সুযোগ দেয় যা কেবলমাত্র ডেটা আবদ্ধ করে এবং তদনুসারে আপনার পরিষেবাগুলির নাম পরিবর্তন করে:

PurchaseService.Purchase(Order order)

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

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

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

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

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

আমার কোড বেসগুলিতে প্রয়োজনীয় জিনিসগুলির জন্য আমার কাছে কোনও কক্ষ নেই


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

আমি অসম্মতি না, ADM DDD হতে পারে যদি আপনি আপনার PurchaseService CashRegister আপনার ডোমেনের ভাষা অংশ কল এবং এটি তৈরি করতে
ইওয়ান

তুমি কি বিস্তারিত বলতে পারো? আমি সর্বদা ভাবতাম যে ওয়াইএমএমভি যখন এডিএম এবং ডিডিডি একটি সলিড জে 2 ইই বা। নেট সি # এমভিসি ইএফ কোডবেসে থাকত।
রিবাল্ড এডি

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

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

3

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

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

সীমাবদ্ধ প্রসঙ্গ ধারণার কারণে ডিডিডি হ'ল মাইক্রো-পরিষেবাগুলির জন্য একটি দুর্দান্ত দৃষ্টান্ত ।

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

সলিড নীতিগুলি সাধারণ উদ্দেশ্য ওওপি ধারণাগুলির একটি সেট যা আপনি আরও ভাল ওওপি কোড তৈরি করতে ব্যবহার করতে পারেন। এগুলি ব্যবহার করে আপনি একটি ভাল ডিডিডি কোডবেস লিখতে পারেন।


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

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

1

একটি সমৃদ্ধ ডোমেন ভাল করা ভাল। একটি দুঃস্বপ্ন যখন না। অ্যানিমিক ডোমেন সবসময় খারাপ থাকে। তবে এটি একটি পরিচিত আরামদায়ক ধরনের খারাপ।

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

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

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

যদি আপনার ঠিক আছে যে ঠিক আছে। আপনি অবশ্যই একমাত্র না।

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

আমার কোড বেসে স্টাফের প্রয়োজন নেই তার জন্য আমার কোনও ঘর নেই।

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


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

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

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

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

1
আপনার দাবির উপর সন্দেহের সুবিধা আমি আপনাকে দিতে যাচ্ছি যে "একটি ভাল সমৃদ্ধ ডোমেন ভাল করার সাথে সাথে ভাল when একটি দুঃস্বপ্ন কখন নয়" " সম্ভবত আমি এটি কখনই ভালভাবে সম্পন্ন হতে দেখিনি, তবে তারপরে আপনি আজেবাজে দাবি করেন যে "রক্তাল্পতা সবসময়ই খারাপ থাকে।" আপনার উত্তরকে মূল্যহীন উপস্থাপনের পক্ষে মতামতযুক্ত বাজে কথা। -1
ডেভিড আরনো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.