ডিডিডি বাউন্ডেড কনটেক্সট এবং ডোমেনগুলি?


16

আমি 10 টি ডাটাবেস সারণী (সমষ্টি, সত্তা / মান অবজেক্টস) এবং ডিডিডি প্রয়োগ করে তুলনামূলকভাবে জটিল অ্যাপ্লিকেশনটিতে কাজ করছি। এই মুহুর্তে এটি মূলত ডিডিডি-লাইট বলে মনে হয় এর অর্থ অ্যাপ্লিকেশন / ডোমেন পরিষেবা, ডোমেন মডেল (সত্তা, মান অবজেক্টস) এবং সংগ্রহস্থলগুলি রয়েছে os

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

বর্তমানে আমি সমষ্টিগত সম্পর্ক দ্বারা ডোমেন মডেলটি সংগঠিত করার চেষ্টা করেছি এবং এটি প্রদর্শনের জন্য নেমস্পেস ব্যবহার করেছি।

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


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

আমার ধারণা আপনি ইতিমধ্যে বুঝতে পেরেছেন কেন আপনার ডোমেনটিকে প্রসঙ্গে ছড়িয়ে দেওয়ার পক্ষে লাভজনক। সুতরাং এখন যা কার্যকর হতে পারে তা হল তাদের চিহ্নিত করার সঠিক প্রসঙ্গ, প্রসঙ্গের সীমানা নির্ধারণ করা। : এখানে কিভাবে আমি এটা করতে হয় medium.com/@wrong.about/...
Zapadlo

উত্তর:


20

এমন একটি সংস্থা বিবেচনা করুন যেখানে কয়েকটি আলাদা বিভাগ রয়েছে:

  • সফটওয়্যার উন্নয়ন
  • এইচআর
  • অ্যাকাউন্টিং

আপনি কি এমন কোনও ব্যবহারকারী মডেল নিয়ে আসতে পারেন যা ব্যবসায়ের সমস্ত ক্ষেত্রকে স্পষ্টভাবে উপস্থাপন করতে পারে? ব্যবহারকারী সত্তা প্রতিটি এক মত দেখতে পারে কি ভেবে দেখুন। সম্ভবত এটি তিনটি পৃথক সত্তায় বিভক্ত:

  • বিকাশকারী
  • কর্মচারী
  • প্রাপ্তা

প্রতিটি প্রসঙ্গে একজন ব্যবহারকারীকে ইনস্ট্যান্ট করার প্রচেষ্টাটি বেশ আলাদা। সম্ভবত এটি এরকম কিছু:

  • নতুন কর্মচারী (এসএসএন, নাম, জোয়ন্ডেট, তারিখের জন্ম, লিঙ্গ)
  • নতুন বিকাশকারী (কর্মচারী, ওয়ার্কস্টেশন, শংসাপত্রসমূহ)
  • নতুন প্রাপক (কর্মচারী, ভূমিকা)

উদাহরণটি ক্ষমা করুন, সঠিক ডোমেন মডেলটি উল্লেখ না করে সঠিকভাবে চিত্রিত করা শক্ত hard

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

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

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


সমর্থনকারী উদাহরণের জন্য ধন্যবাদ যা খ্রিস্টপূর্ব 3 টির বিভিন্ন প্রয়োজনের চিত্রিত করতে সহায়তা করে।
lko

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

@ রোগারিও আপনার আপত্তি আসলে প্রতিটি
সীমান্ত

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

16

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

  • পণ্য ক্যাটালগ, যেখানে আপনি আপনার পণ্যের বিবরণ এবং সমস্ত বৈশিষ্ট্য রাখেন keep
  • ইনভেন্টরি, যেখানে আপনার পণ্য স্টক স্তর রয়েছে

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

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

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


1
সদৃশতা আনার জন্য +1। এটি প্রথমে কিছুটা বিভ্রান্তিকর ("আমি কি এই ভুল করছি ?!) তবে এটি সম্পূর্ণ প্রাকৃতিক, অনেক ক্ষেত্রেই
অ্যাড্রিয়ান স্নাইডার

এই Productদৃশ্যে এই শ্রেণিগুলি উভয়ই হাইপোটিকভাবে একই আইডি ভাগ করে নিচ্ছে (যেমন পৃথক বিসি উভয় টেবিলেরই কোনও একক পণ্য আইডি সহ কোনও টেবিলে বিদেশী কী রয়েছে)? সম্ভবত ডোমেন ইভেন্টের সাথে যোগাযোগ করার সময় তারা সেই আইডি ব্যবহার করতে পারে?
lko

1
এটি সমস্ত কি স্টোরেজ চয়ন করা হয় তার উপর নির্ভর করে। ক্রস-ডোমেন উল্লেখ করার জন্য প্রযুক্তিগত আইডি ব্যবহার করার প্রয়োজন নেই। আন্তঃসম্পর্কীয় যোগাযোগ করাও ঠিক হবে না।
আলেক্সি জিমেরেভ

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