কীভাবে স্পষ্টভাবে একটি সীমাবদ্ধ প্রসঙ্গের সীমানা নির্ধারণ করতে হয়


9

ডিডিডি পড়ার এবং গবেষণা করার এক মাস বা তার পরে, আমি নিজের প্রকল্প শুরু করার সিদ্ধান্ত নিয়েছি এবং এই সীমানা প্রসঙ্গে> ডিডিডি তৈরি করেছি

  • ক্লায়েন্টদের মধ্যে
  • পণ্য
  • অর্ডার
  • বিলিং

প্রতিটি সীমানা প্রসঙ্গে একটি উপস্থাপনা স্তর, ডোমেন স্তর, ধ্রুবক স্তর হিসাবে বিশ্রাম এপিআই থাকে।

এখন পর্যন্ত খুব ভাল, কোডটি মসৃণ চলছে, তবে একচেটিয়া বিশ্ব থেকে এসে আমি এখনও নিম্নলিখিতগুলি বের করার চেষ্টা করছি:

  • যখন আমি একটি নতুন ক্লায়েন্ট তৈরি করতে চাই, নতুন চালান জারি করি, নতুন ক্রম তৈরি করতে চাই আমি উদাহরণস্বরূপ দেশগুলির অ্যাক্সেসের তালিকাটি চাই। আমি কি:

ক) প্রতিটি বিসি-তে দেশগুলির একটি তালিকা তৈরি করুন

খ) একটি দেশ বিসি -> এপিআই তৈরি করুন এবং উপলব্ধ দেশের তালিকা পেতে এটি ব্যবহার করুন

গ) তৃতীয় পক্ষের এপিআই ব্যবহার করুন এবং প্রতিটি বিসি-তে অ্যান্টিঅরকশন লেয়ারের মাধ্যমে ডেটা টানুন

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

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


2
মনে রাখবেন যে ডেডি নকলটি ডিডিডি-তে প্রাথমিক উদ্বেগ নয় ...
জন

উত্তর:


7

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

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

এই বিসিগুলিতে আপনি বিশেষ্যগুলিতে মনোনিবেশ করেন না। আপনি ব্যবহারের ক্ষেত্রে মনোনিবেশ করেন এবং বিশেষ্যগুলির এমন মডেল তৈরি করেন যা ব্যবহারের ক্ষেত্রে পূরণ করতে পারে। "সামগ্রিক মূল" এর পদ্ধতিগুলি ব্যবহারের ক্ষেত্রে মৃত্যুদন্ড কার্যকর করে এবং সম্পর্কিত মডেলগুলিতে যথাযথ পরিবর্তন করে।

... সমস্ত মডেল ভুল, কিন্তু কিছু দরকারী।

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

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


3

আপনার প্রশ্নগুলি থেকে, আমি মনে করি আপনি সীমাবদ্ধ প্রসঙ্গে ভুল বুঝবেন। আপনি নীল বইয়ের 14 অধ্যায়টি আবার পড়তে চাইতে পারেন ।

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

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

দ্বিতীয় প্রশ্ন যা আপনাকে উত্থাপন করা দরকার তা হল আপনার ভাগ করা মডেলগুলির মধ্যে কোনটি "ভাগ করা" ডেটা রেকর্ডের বই। "দেশ" এর ক্ষেত্রে সঠিক উত্তর সম্ভবত তাদের কেউই নয়! ভূ-রাজনৈতিক টপোলজি আপনার মডেল দ্বারা নিয়ন্ত্রিত হয় না।

যখন কোনও দেশ বিদেশী শক্তি দ্বারা দখল করা হয় তখন আপনার ডোমেন মডেলগুলিতে কী হওয়ার কথা?

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


0

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


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

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

0

এই বিষয়ে আমার গ্রহণযোগ্যতা হ'ল ব্যবসায়ের সক্ষমতা ম্যাপিং বা মান-চেইন বিশ্লেষণের মতো অন্যান্য অনুরূপ কৌশলগুলি ব্যবহার করে সীমাবদ্ধ প্রসঙ্গটি নির্ধারণ করা । এটি নিম্নলিখিত পদক্ষেপে নেমে আসে:

  1. আপনার সিস্টেমের উচ্চ-স্তরের দায়িত্ব বা ব্যবসায়-দক্ষতার সংজ্ঞা দিন। আমি মনে করি এটি করার সর্বোত্তম উপায় হ'ল আপনার এন্টারপ্রাইজটি ব্যবসায়ের মূল্য অর্জনের জন্য যে পদক্ষেপগুলি নিয়েছে তার সাথে জাঁকজমক করা। আপনি যে যৌক্তিক সীমানা নিয়ে এসেছেন তা হ'ল আপনার ব্যবসায়িক পরিষেবাগুলি, বা, যদি আপনি চান তবে সীমাবদ্ধ প্রসঙ্গ।
  2. প্রতিটি পরিষেবার মধ্যে আরও গভীরভাবে বিতরণ করুন।
  3. প্রথম দুটি পয়েন্ট পাশাপাশি আপনার পরিষেবাগুলির মধ্যে যোগাযোগ শনাক্ত করুন।

সুতরাং আপনার ব্যবসায় কীভাবে পরিচালিত হয় সেদিকে প্রাথমিক ফোকাস।

ব্যবহারিক পরামর্শ দম্পতি:

  1. যদি আপনার কোনও প্রসঙ্গ / পরিষেবাদি / ইত্যাদির জন্য অন্য কোনও প্রসঙ্গের ডেটা প্রয়োজন হয় তবে সম্ভবত আপনার সীমানা ভুল।
  2. প্রসঙ্গ যোগাযোগের অত্যন্ত কাঙ্ক্ষিত উপায় ইভেন্ট-ভিত্তিক। এটি স্কেলাবিলিটি এবং নির্ভরযোগ্যতার মূল চাবিকাঠি। আপনার যদি সিঙ্ক্রোনাস যোগাযোগের প্রয়োজন হয় তবে সম্ভবত আপনার গণ্ডিগুলি ভুল নয়, আবার। তদ্ব্যতীত, সিঙ্ক্রোনাস যোগাযোগ আপনার সিস্টেমকে হত্যা করবে।
  3. আপনার ডোমেনটি আপনি যা ভাবেন তার চেয়ে শেষ পর্যন্ত সামঞ্জস্যপূর্ণ। অন্য সবার মতোই। সবকিছুকে 100% সামঞ্জস্য করার চেষ্টা করবেন না। এটিতে কোনও ব্যবহারিক জ্ঞান নেই।
  4. প্রসঙ্গগুলি অর্কেস্ট্রেটেড করার দরকার নেই। তারা স্বনির্ভর হয়। মানুষের মতো।

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

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