ডিডিডি অ্যাপ্লিকেশন পরিষেবা এবং আরএসটি এপিআইয়ের মধ্যে ধারণাগত অমিল mis

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

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

userService.ChangeName(name);
userService.ChangeEmail(email);

এই অ্যাপ্লিকেশন পরিষেবাটির API কমান্ডগুলি (ক্রিয়াগুলি, পদ্ধতিগুলি) প্রকাশ করে, রাষ্ট্রকে নয়।

তবে যদি আমাদের একই অ্যাপ্লিকেশনটির জন্য একটি RESTful এপিআই সরবরাহ করতে হয় তবে একটি ব্যবহারকারী সংস্থান মডেল রয়েছে যা দেখতে এটির মতো দেখাচ্ছে:

{
name:"name",
email:"email@mail.com"
}

রিসোর্স-ওরিয়েন্টেড এপিআই কমান্ড নয়, রাষ্ট্রকে প্রকাশ করে । এটি নিম্নলিখিত উদ্বেগ উত্থাপন করে:

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

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

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

প্রশ্নাবলী:

এই সমস্ত জটিলতাটি কি কেবলমাত্র একটি (ঘন) আরএসটি-টু-অ্যাপ্লিকেশন পরিষেবা ম্যাপিং স্তর দ্বারা পরিচালনা করা উচিত?
বা আমি ডিডিডি / আরএসএসটি সম্পর্কে আমার বোঝার মধ্যে কিছু মিস করছি?
বিশ্রামটি কি কোনও নির্দিষ্ট (মোটামুটি কম) ডিগ্রি জটিলতায় ডোমেন মডেলগুলির কার্যকারিতা প্রকাশের জন্য ব্যবহারিক হতে পারে না?

architecture rest domain-driven-design

— astreltsov
সূত্র

আমি ব্যক্তিগতভাবে রেস্টকে প্রয়োজনীয় বিবেচনা করি না। তবে এটিতে ডিডিডি জুতা দেওয়া সম্ভব: ইনকিউকিউ.আর্টিক্যালস / রেস্ট- এপিআই- ওসিকিআরএস প্রোগ্রামারস.স্ট্যাকেক্সচেঞ্জ / সেকশনস

— ড্যান

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

— করম্যাক মুলহাল

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

— করম্যাক মুলহাল

আপনার ডোমেনে আরএসটি রাষ্ট্রের পরিবর্তনের পার্শ্ব প্রতিক্রিয়া হিসাবে আপনার ডোমেন এবং ওয়েবকে

— করম্যাক মুলহল

আমি পুরো "রোবট / স্টেট মেশিন হিসাবে ব্যবহারকারী" জিনিস সম্পর্কে নিশ্চিত নই। আমি মনে করি আমাদের ব্যবহারকারীর ইন্টারফেসগুলি তার চেয়ে অনেক বেশি প্রাকৃতিকভাবে গড়ে তোলার জন্য আমাদের প্রচেষ্টা করা উচিত ...

— guillaume31

উত্তর:

আমি একই সমস্যাটি পেয়েছি এবং REST সংস্থানগুলি আলাদাভাবে মডেলিং করে এটি "সমাধান" করেছি, যেমন:

/users/1  (contains basic user attributes) 
/users/1/email 
/users/1/activation 
/users/1/address

সুতরাং আমি মূলত বৃহত্তর, জটিল সংস্থানটি কয়েকটি ছোট ছোটগুলিতে বিভক্ত করেছি। এর প্রত্যেকটিতে মূল সংস্থানটির কিছুটা সমন্বিত গ্রুপ রয়েছে যা একত্রে প্রক্রিয়াজাত হওয়ার আশা করা হয়।

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

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

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

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

— qbd
সূত্র

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

— অ্যাস্ট্রেলেটসভ

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

— কিবিডি

সুতরাং সার্ভারে একটি জিইটি অনুরোধ এক বা একাধিক প্রকৃত ক্যোয়ারিতে অনুবাদ করে (কতটি সাব-রিসোর্স অন্তর্ভুক্ত রয়েছে তার উপর নির্ভর করে) যা একটি একক সংস্থান সামগ্রীতে যুক্ত হয়?

— অ্যাস্ট্রেলત્সভ

যদি একাধিক স্তরের বাসা বাঁধতে হয় তবে কী হবে?

— অ্যাস্ট্রেলત્সভ

হ্যাঁ, সম্পর্কিত ডিবিএসে এটি সম্ভবত একাধিক ক্যোয়ারিতে অনুবাদ করবে to নির্বিচারে নেস্টিং জেএসএন

— qbd

এখানে মূল বিষয়টি হ'ল, যখন কোনও REST কল করা হয় তখন ব্যবসায়ের যুক্তিটি কীভাবে স্বচ্ছভাবে শুরু করা হয়? এটি এমন একটি সমস্যা যা আরইএসটি দ্বারা সরাসরি সমাধান করা হয় না।

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

উপরের উদাহরণটি ব্যবহার করে, নামের ক্ষেত্রটি যখন REST ব্যবহার করে পরিবর্তন করা হয় তখন আমরা ভ্যালিডনেম নামে একটি ব্যবসায় যুক্তিযুক্ত পদ্ধতিতে আবেদন করতে পারি:

class User { 
      String name;
      String email;

      /**
       * This method will be transparently invoked when the value of name is changed
       * by REST.
       * The XorUpdate annotation becomes effective for PUT/POST actions
       */
      @XorPostChange
      public void validateName() {
        if(name == null) {
          throw new IllegalStateException("Name cannot be set as null");
        }
      }
    }

আপনার নিষ্পত্তি করার মতো একটি সরঞ্জামের সাহায্যে, আপনাকে যা করতে হবে তা হ'ল আপনার ব্যবসায়ের লজিক পদ্ধতিগুলিকে যথাযথভাবে মন্তব্য করতে হবে।

— codedabbler
সূত্র

রিসোর্স-ওরিয়েন্টেড পদ্ধতিতে ডোমেন মডেলটি প্রকাশ করার উপায় নিয়ে আসতে আমার কিছুটা সমস্যা হচ্ছে।

আপনার কোনও উত্স ভিত্তিক পদ্ধতিতে ডোমেন মডেলটি প্রকাশ করা উচিত নয়। আপনার উচিত অ্যাপ্লিকেশনটি একটি উত্স-ভিত্তিক উপায়ে প্রকাশ করা উচিত।

যদি ইউআই আরও কমান্ড-ভিত্তিক হয়, যা প্রায়শই ঘটে থাকে, তবে আমাদের ক্লায়েন্টের পক্ষ থেকে কমান্ড এবং সংস্থানগুলির মধ্যে ম্যাপ করতে হবে এবং তারপরে এপিআই সাইডে ফিরে যেতে হবে।

মোটেও নয় - অ্যাপ্লিকেশন সংস্থানগুলিতে কমান্ডগুলি প্রেরণ করুন যা ডোমেন মডেলটির সাথে ইন্টারফেস করে।

একটি REST এপিআই এর বিপরীতে প্রতিটি আপডেট অপারেশন রিসোর্স মডেলটিতে কী কী বৈশিষ্ট্যগুলি আপডেট করা হচ্ছে তার উপর নির্ভর করে এক বা একাধিক অ্যাপ্লিকেশন পরিষেবা পদ্ধতি কলকে ম্যাপ করতে পারে

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

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

আপনি এখানে ভুল লেজ তাড়া করছেন।

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

এখন কি ঘটছে? ব্যবহারকারীর দৃষ্টিকোণ থেকে এটি করা একক পরমাণু কাজ। ডোমেনমোডেলের দৃষ্টিকোণ থেকে, এটি সমষ্টি দ্বারা পরিচালিত বেশ কয়েকটি কমান্ড, যেখানে প্রতিটি কমান্ড পৃথক লেনদেনে পরিচালিত হয় run এগুলি সম্পূর্ণ বেমানান! ফাঁক কাটাতে আমাদের মাঝখানে কিছু দরকার!

কিছু হ'ল "অ্যাপ্লিকেশন"।

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

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

এখন, আপনি যে অ্যাপ্লিকেশন নির্মিত হয়েছে তা কল্পনা করুন; আপনি কীভাবে এটি একটি বিশ্রামজনক উপায়ে ইন্টারঅ্যাক্ট করবেন?

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

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

এই রূপকথায়, উত্সটি নিজেই টাস্ককে উপস্থাপন করে - আপনি টাস্ক রিসোর্সে উপযুক্ত প্রতিনিধিত্ব পোস্ট করে কার্যটির একটি নতুন উদাহরণ শুরু করেন, এবং সেই সংস্থানটি অ্যাপ্লিকেশনটির সাথে ইন্টারফেস করে আপনাকে পরবর্তী অ্যাপ্লিকেশন স্থিতিতে নির্দেশ দেয়।

ইন DDD , প্রায় কাছাকাছি যে কোনো সময় আপনি একাধিক কমান্ড সমন্বয়ের করছেন, তখন আপনি (কাহিনী ওরফে ব্যবসায়িক প্রক্রিয়ার ওরফে) একটি প্রক্রিয়া পরিপ্রেক্ষিতে চিন্তা করা চাই।

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

আরও দেখুন: রিমাস্ট অনুশীলনে জিম ওয়েবার।

— VoiceOfUnreason
সূত্র

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

— আইবারোদেভ