স্বায়ত্তশাসিত মাইক্রোসার্ভেসিস, ইভেন্টের সারি এবং পরিষেবা আবিষ্কার


15

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

  1. মাইক্রো-সার্ভিসেস আর্কিটেকচারটি ডোমেন চালিত ডিজাইনের সাথে ভাল যায়। সাধারণত একটি এমএস একটি সীমাবদ্ধ প্রসঙ্গ উপস্থাপন করে।
  2. যদি মাইক্রো পরিষেবা A এর কার্যকারিতা প্রয়োজন যা মাইক্রো পরিষেবা বিতে থাকে তবে আমার মডেলটি সম্ভবত ভুল এবং A এবং B প্রকৃতপক্ষে একটি মাইক্রো পরিষেবা / বিসি হওয়া উচিত।
  3. মাইক্রো-পরিষেবাগুলির (সরাসরি এইচটিটিপি অনুরোধগুলি) মধ্যে সুসংগত যোগাযোগ খারাপ, কারণ এটি মাইক্রো-পরিষেবাগুলির উদ্দেশ্যকে অস্বীকার করে এবং উপাদানগুলির মধ্যে সংযোগের পরিচয় দেয়।
  4. পরিষেবাগুলির মধ্যে অ্যাসিনক্রোনাস যোগাযোগ আকাঙ্খিত। পরিষেবাদির বার্তাগুলির কাতারে ইভেন্টগুলি প্রকাশ করা উচিত, যাতে অন্যান্য পরিষেবাদি ইভেন্টটির অংশটি সাবস্ক্রাইব করতে এবং প্রক্রিয়া করতে পারে বা তাদের প্রসঙ্গে প্রয়োজনীয় ডেটার অংশটিকে প্রতিলিপি করতে এটি ব্যবহার করতে পারে। এইভাবে, পরিষেবাগুলি অনুরোধগুলি প্রক্রিয়া করতে পারে এমনকি অন্যান্য পরিষেবাগুলি নিচে রয়েছে, যা সিঙ্ক্রোনাস যোগাযোগের ক্ষেত্রে হবে না।
  5. যদি মাইক্রো-পরিষেবা ইভেন্ট প্রকাশ করে, মাইক্রো-পরিষেবা বি সেই ইভেন্টটির সদস্যতা গ্রহণ করে এবং ফলাফল হিসাবে একটি নতুন ইভেন্ট উত্পন্ন করে, মাইক্রো-পরিষেবা নতুনভাবে তৈরি হওয়া কোনও ইভেন্ট নয়, কারণ এটি একটি বিজ্ঞপ্তি নির্ভরতা হবে। এই ক্ষেত্রে, আমরা তৃতীয় মাইক্রো-সেবা পরিচয় করিয়ে, অথবা মেশা উচিত একটি এবং বি করার জন্য এবি মাইক্রো-সেবা।
  6. মাইক্রো-পরিষেবাটি আসলে একটি বিভ্রান্তিকর শব্দ। আমাদের ছোট ছোট প্রসঙ্গে লড়াই করার চেষ্টা করা উচিত, তবে এটি হওয়ার দরকার নেই। মেয়াদটি "মাইক্রো-পরিষেবা" হওয়া উচিত নয়, " কাজের পরিষেবাটি করার পক্ষে যথেষ্ট বড় "।
  7. মাইক্রো-পরিষেবাগুলি আমাদের আরও স্বাচ্ছন্দ্য এবং ভয় ছাড়াই নতুন কার্যকারিতা প্রবর্তন করতে দেয় যে আমরা পুরো সিস্টেমটি ভেঙে দেব। এটি একটি নতুন পরিষেবা প্রবর্তন করে বা বিদ্যমান কোনওটির রিফ্যাক্টরিংয়ের মাধ্যমে করা যেতে পারে।
  8. প্রতিটি মাইক্রো-সেবার নিজস্ব ডেটা-স্টোরেজ থাকা উচিত। এই আর্কিটেকচারে ডেটা অনুলিপি / নকলকরণ আকাঙ্ক্ষিত আচরণ।

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

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

উত্তর:


4

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

আমি তবে পুরোপুরি 2, 5 এবং 8 সমর্থন করি না:

  • 2) একটি সাধারণ নির্ভরতা স্বয়ংক্রিয়ভাবে একত্রীকরণের দিকে পরিচালিত করা উচিত নয়। আপনাকে এই ধরনের নির্ভরশীল কলগুলির ফ্রিকোয়েন্সি এবং অন্যান্য পরিষেবাগুলির কলগুলির ফ্রিকোয়েন্সি বিবেচনা করতে হবে।

    সুতরাং যদি একটি মাইক্রোসার্চ এ এর ​​খুব ঘন ঘন মাইক্রোসার্চ বিতে কার্যকারিতা প্রয়োজন হয় এবং মাইক্রোসার্চিস বি খুব কমই অন্যান্য মাইক্রোসার্ভিসগুলির দ্বারা প্রয়োজন হয়, আপনার কল্পনা করা কাঠামোকে চ্যালেঞ্জ জানানো উচিত এবং জিজ্ঞাসা করা উচিত যে এটি উভয় মাইক্রো সার্ভিসেসকে গ্রুপ করার জন্য আরও উপযুক্ত নয় কিনা।

  • 5) অবশ্যই, আপনাকে বার্তা হ্যান্ডলিংয়ে অন্তহীন সাইকেল চালনা এড়াতে হবে।

    তবে কোনও মধ্যস্থতাকারী যুক্ত করা এটি প্রতিরোধ করবে না: A সি দ্বারা পরিচালিত একটি বার্তা চালু করতে পারে যিনি বি দ্বারা পরিচালিত একটি বার্তা প্রবর্তন করেন, যিনি এ দ্বারা পরিচালিত একটি বার্তা প্রবর্তন করেন এবং আপনি এখানে লুপে আটকে আছেন।

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

  • 8) হ্যাঁ, প্রতিটি মাইক্রোসারওয়াইসের এর ডেডিকেটেড স্টোরেজ / ডাটাবেস থাকতে হবে।

    পরিষেবাগুলি স্বতন্ত্র হতে দেওয়ার জন্য সর্বনিম্ন প্রতিরূপের প্রয়োজন। তবে আমি এতদূর যেতে পারব না যে প্রতিলিপিটি পছন্দসই: প্রতিরূপ প্রক্রিয়াগুলির মাধ্যমে লুকানো দম্পতি এড়াতে এটি সর্বনিম্ন রাখতে হবে।

    মাইক্রোসার্ভিসেসগুলি আলগা দম্পতি সম্পর্কে। এটি কখনও কখনও আরও কার্যকরভাবে সম্পর্কিত তথ্য পুনরুদ্ধার করার জন্য অন্য মাইক্রোসার্চিসে কল করে তথ্যের অনুলিপি না করে অর্জন করা যেতে পারে।

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


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

1
এখানে কোনো নির্ভুল সমাধান: এটি আলগা কাপলিং এবং এনক্যাপস্যুলেশন (হয় microservices.io/patterns/data/database-per-service.html ) easyness কিন্তু অতিরেক (বিরুদ্ধে ব্যালেন্সে microservices.io/patterns/data/event-driven-architecture .html ) সামগ্রিক চিত্রের প্রসঙ্গে ( মাইক্রোসার্ভেস.আই.ও. / পেটার্নস / মাইক্রোসার্ভেস.চটিএমএল )
ক্রিস্টোফ

3

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

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

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

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

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

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


2
  1. মাইক্রো-সার্ভিসেস আর্কিটেকচারটি ডোমেন চালিত ডিজাইনের সাথে ভাল যায়। সাধারণত একটি এমএস একটি সীমাবদ্ধ প্রসঙ্গ উপস্থাপন করে।

একমত নন। ডিডিডি খুব ওও হতে থাকে। একটি আদেশ প্রদান করা হয়? অর্ডার.ডেলিভার () যেখানে মাইক্রো পরিষেবাগুলিতে ডেলিভারি সার্ভিস থাকবে D ডেলিভার (অর্ডার)

  1. যদি মাইক্রো পরিষেবা A এর কার্যকারিতা প্রয়োজন যা মাইক্রো পরিষেবা বিতে থাকে তবে আমার মডেলটি সম্ভবত ভুল এবং A এবং B প্রকৃতপক্ষে একটি মাইক্রো পরিষেবা / বিসি হওয়া উচিত।

অসম্মতি, আপনার চেষ্টা করা উচিত এবং আপনাকে মাইক্রো পরিষেবাগুলি মাইক্রো রাখা উচিত। এগুলি আরও ছোট করে দিন!

  1. মাইক্রো-পরিষেবাগুলির (সরাসরি এইচটিটিপি অনুরোধগুলি) মধ্যে সুসংগত যোগাযোগ খারাপ, কারণ এটি মাইক্রো-পরিষেবাগুলির উদ্দেশ্যকে অস্বীকার করে এবং উপাদানগুলির মধ্যে সংযোগের পরিচয় দেয়।

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

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

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

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

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

  1. মাইক্রো-পরিষেবাটি আসলে একটি বিভ্রান্তিকর শব্দ। আমাদের ছোট ছোট প্রসঙ্গে লড়াই করার চেষ্টা করা উচিত, তবে এটি হওয়ার দরকার নেই। মেয়াদটি "মাইক্রো-পরিষেবা" হওয়া উচিত নয়, "কাজের পরিষেবাটি করার পক্ষে যথেষ্ট বড়"।

একমত নন। ন্যানো-পরিষেবাগুলি দেখুন।

  1. মাইক্রো-পরিষেবাগুলি আমাদের আরও স্বাচ্ছন্দ্য এবং ভয় ছাড়াই নতুন কার্যকারিতা প্রবর্তন করতে দেয় যে আমরা পুরো সিস্টেমটি ভেঙে দেব। এটি একটি নতুন পরিষেবা প্রবর্তন করে বা বিদ্যমান কোনওটির রিফ্যাক্টরিংয়ের মাধ্যমে করা যেতে পারে।

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

  1. প্রতিটি মাইক্রো-সেবার নিজস্ব ডেটা-স্টোরেজ থাকা উচিত। এই আর্কিটেকচারে ডেটা অনুলিপি / নকলকরণ আকাঙ্ক্ষিত আচরণ।

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


1

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

এবং আপনার অন্য প্রশ্নে, সারি ভিত্তিক যোগাযোগের জন্য পরিষেবা আবিষ্কারের প্রয়োজন নেই।


0

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

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

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

উদাহরণস্বরূপ, অন্যান্য উত্তরে যা কিছু বলা হয়েছিল তা হ'ল ওওপি সম্পর্কে পাঠ্যপুস্তকের বিবৃতি।


0

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

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

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

এই পদ্ধতির ব্যবহার করে পরিষেবার সীমানা চিহ্নিত করার একটি উদাহরণ এখানে

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