ডিডিডি সমষ্টিগুলির সিরিয়ালকরণের জন্য সেরা অনুশীলন


23

ডিডিডি অনুসারে ডোমেন যুক্তি প্রযুক্তিগত উদ্বেগ যেমন সিরিয়ালাইজেশন, অবজেক্ট-রিলেশনাল ম্যাপিং ইত্যাদি দ্বারা দূষিত হওয়া উচিত নয় should

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

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

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

আমি DDD ডোমেন অবজেক্টের (সত্তা এবং মান অবজেক্টের সমন্বয়ে) সামগ্রিক অবস্থা সিরিয়ালিয়াল করতে আগ্রহী। এটি সাধারণ বা ট্রান্সকেশন স্ক্রিপ্টের পরিস্থিতিতে সিরিয়ালাইজেশন সম্পর্কে নয় যেখানে স্টেটলেস পরিষেবাগুলি সাধারণ ডেটা ধারক বস্তুগুলিতে কাজ করে।

উত্তর:


12

ধরণের জিনিস

আমাদের আলোচনার উদ্দেশ্যে, আসুন আমাদের বস্তুগুলিকে তিনটি ভিন্ন ধরণের মধ্যে পৃথক করা যাক:

ব্যবসায় ডোমেন যুক্তি

এগুলি হ'ল কাজগুলি হয়ে ওঠে। তারা একটি চেকিং অ্যাকাউন্ট থেকে অন্যটিতে অর্থ স্থানান্তর করে, অর্ডারগুলি পরিপূরণ করে এবং আমরা ব্যবসায়িক সফ্টওয়্যারটি প্রত্যাশা করি এমন অন্যান্য ক্রিয়াকলাপগুলি

ডোমেন লজিক অবজেক্টগুলিতে সাধারণত অ্যাকসেসর (গেটার্স এবং সেটটার) প্রয়োজন হয় না। বরং আপনি কোনও কনস্ট্রাক্টরের মাধ্যমে নির্ভরতা হস্তান্তর করে অবজেক্টটি তৈরি করেন এবং তারপরে পদ্ধতিগুলির মাধ্যমে অবজেক্টটি ম্যানিপুলেট করুন (বলুন, জিজ্ঞাসা করবেন না)।

ডেটা স্থানান্তর অবজেক্টস

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

মডেল অবজেক্টস দেখুন

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

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

ক্রমিকায়ন, নির্ভরতা এবং সংযুক্তকরণ

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

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

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


আমি decoupling আপনার মতামত সঙ্গে একমত। সিরিয়ালাইজারটি ডোমেন অবজেক্টের উপর নির্ভর করে এবং এটি ঠিক আছে। তবে অন্যভাবে নয়। আমি ডোমেন অবজেক্টগুলিতে পাবলিক অ্যাক্সেসরদের সম্পর্কে আপনার মতামতের সাথে একমত নই। অনুশীলনে তাদের প্রায়শই থাকে, হ্যাঁ। তবে আইএমও ক্লিন অবজেক্ট-ভিত্তিক ডিজাইনে ডোমেন লজিক প্রয়োগ করা পছন্দনীয় হবে: বলুন, জিজ্ঞাসা করবেন না । তবে তবুও আপনাকে ম্যাপিংয়ের উদ্দেশ্যে অ্যাক্সেসরের প্রয়োজন (ওআরএম, সিরিয়ালাইজেশন, জিইউআই ...)। যদি সম্ভব হয় তবে আমি এড়াতে চাই।
agগলবিয়াক

আপনার ক্ষেত্রগুলি অ্যাক্সেস করার কীভাবে পরিকল্পনা করবেন, যদি আপনার অ্যাক্সেসর না থাকে?
রবার্ট হার্ভে

প্রকৃতপক্ষে আমি বর্ণিত তিন ধরণের অবজেক্টের মধ্যে কোনওটিরই উল্লেখ করছি না, তবে ডিডিডি পরিভাষা এবং তাদের উপ-বস্তুর (সত্তা, মান বস্তু) "সমষ্টি" হিসাবে to আমি এখন বুঝতে পারি, আমার প্রশ্নটি এ সম্পর্কে যথেষ্ট স্পষ্ট ছিল না। দুঃখিত! উপরে আমার সম্পাদনা দেখুন।
গলবিয়াক

1
এটি মূলত অমীমাংসিত সমস্যা - আপনার এনক্যাপসুলেশন, ডিকোপলিং এবং সিরিয়ালাইজেশন থাকতে পারে না DT একই সাথে ডিটিও এক্সপোজার করার সময় এনকোডিং করা আপোষ অর্জনের এক উপায়। : আছে, তবে, অনেক কম অনধিকারমূলক উপায়ে yegor256.com/2016/07/06/data-transfer-object.html
Basilevs

1
এটি এম্পসুলেশন হ্রাস করে, যে কেউ বস্তুর ইন্টার্নাল পড়তে বন্ধু শ্রেণি প্রয়োগ করতে বা ব্যবহার করতে পারে use
বাসিলিভস

-1

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

সিরিয়ালাইজেশনের সবচেয়ে সহজ এবং সবচেয়ে দৃ approach় পদ্ধতিকে হ'ল ডেটাটিকে এক প্রকার অজ্ঞাব্য বিন্যাসে অনুবাদ করা যা কাঠামোটিকে একটি সহজ এবং সহজেই ব্যবহারযোগ্য বিন্যাসে বজায় রাখে। উদাহরণস্বরূপ, সর্বব্যাপী সিরিয়ালাইজেশন ফর্ম্যাটগুলি (যেমন জেএসএন, এক্সএমএল) একটি সু-সংজ্ঞায়িত পাঠ্য-ভিত্তিক ফর্ম্যাট ব্যবহার করে। পাঠ্য উত্পাদন, প্রেরণ এবং গ্রাস করা সহজ।

এই দুটি ফর্ম্যাট ব্যবহার করার জন্য আদর্শ নাও হতে পারে এমন দুটি কারণ রয়েছে।

  1. দক্ষতা

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

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

  2. স্পষ্টতা

    Intendedালাইটি প্রয়োজনীয়ভাবে ডেটা অজিনোস্টিক টাইপ থেকে ডেটা সিরিয়ালাইজ / ডিসায়ারাইজ করার দরকার হয় ফলে নির্ভুলতার ক্ষতি হয়।

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

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


দুঃখিত, তবে এটি আমার প্রশ্নের উত্তর দেয় না। এটি সিরিয়ালাইজেশন থেকে ডোমেন অবজেক্টগুলি ডিকোলিং সম্পর্কে, সিরিয়ালাইজেশনের কারণগুলি বা বিভিন্ন ফর্ম্যাটের উপকারিতা এবং কনস সম্পর্কে নয়। আমি কীভাবে ডোমেন অবজেক্টগুলিকে প্রকাশ্যে তাদের ব্যক্তিগত অবস্থা প্রকাশ না করে সিরিয়ালাইজ করব?
agগলবীক

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

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

আমি পাবলিক অ্যাক্সেসরগুলি সম্পর্কে সিরিয়ালযুক্ত করার জন্য সাধারণত বস্তুগুলিতে ধারনা করা সম্পর্কে সম্মত। তবে আমি কীভাবে এটি ডিডিডি এর সাথে সম্পর্কিত এবং ডোমেন লজিকের এনক্যাপসুলেশনে এর দৃ strong় ফোকাসের বিষয়ে আরও জানতে চাই। সমস্ত ডিডিডি প্র্যাকটিশনাররা কি সিরিয়ালাইজেশনের জন্য পাবলিক অ্যাকসেসরগুলির মাধ্যমে ডোমেন মডেলের রাজ্যটি উন্মোচন করে (এবং তাদের উদাহরণে এটি কখনই উল্লেখ করে না)? আমি এটাকে সন্দেহ করি. দয়া করে আমাকে ভুল করবেন না আমি আপনার ইনপুট খুব প্রশংসা করি। এটা ঠিক যে আমি অন্য দিকটিতে আগ্রহী। (এখনও অবধি আমার মনে হয় না যে আমার প্রশ্নটি খুব অস্পষ্ট, তবে রবার্ট হার্ভির উত্তর এবং আপনারা আমাকে সে সম্পর্কে ভাবতে পেয়েছেন ..)
agগলবিক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.