সমৃদ্ধ বনাম অ্যানমিক ডোমেন মডেল [বন্ধ]

Question 1

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

10 মাস আগে বন্ধ ছিল ।

এই প্রশ্নটি উন্নত করুন

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

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

আমি এরিক ইভানের ডিডিডি বইটি পড়েছি এবং তিনি (ফওলর এবং অন্যান্যদের সাথে) মনে করেন অ্যানিমিক ডোমেন মডেলগুলি একটি বিরোধী নিদর্শন।

সুতরাং আমি সত্যিই এই সমস্যাটি সম্পর্কে কিছু অন্তর্দৃষ্টি পেতে চাইছিলাম।

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

Question 2

পার্থক্যটি হ'ল অ্যানিমিক মডেলটি যুক্তিটিকে ডেটা থেকে আলাদা করে। যুক্তিবিজ্ঞান প্রায়ই নামে ক্লাসের স্থাপন করা হয় **Service, **Util, **Manager, **Helperএবং তাই। এই শ্রেণিগুলি ডেটা ব্যাখ্যার যুক্তি প্রয়োগ করে এবং তাই ডেটা মডেলটিকে একটি আর্গুমেন্ট হিসাবে গ্রহণ করে। যেমন

public BigDecimal calculateTotal(Order order){
...
}

সমৃদ্ধ ডোমেন পদ্ধতির তথ্যের ব্যাখ্যার যুক্তি সমৃদ্ধ ডোমেন মডেলটিতে রেখে বিপরীত হয়। সুতরাং এটি যুক্তি এবং ডেটা একসাথে রাখে এবং একটি সমৃদ্ধ ডোমেন মডেল এর মতো দেখায়:

order.getTotal();

এটি অবজেক্টের ধারাবাহিকতায় একটি বড় প্রভাব ফেলে। যেহেতু ডেটা ব্যাখ্যার যুক্তি যুক্ত করে ডেটা গুটিয়ে দেয় (পদ্ধতিগুলি কেবলমাত্র বস্তুর পদ্ধতির মাধ্যমে অ্যাক্সেস করতে পারে) পদ্ধতিগুলি অন্যান্য ডেটার স্থিতি পরিবর্তনের ক্ষেত্রে প্রতিক্রিয়া জানাতে পারে -> এটাকে আমরা আচরণ বলে থাকি।

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

গভীর অন্তর্দৃষ্টির জন্য আমার ব্লগটি একবার দেখুন https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Question 3

বোজিদার বোজনভ এই ব্লগ পোস্টে রক্তাল্পতার মডেলের পক্ষে তর্ক করছেন বলে মনে হচ্ছে ।

এখানে তিনি উপস্থাপন করেছেন সংক্ষিপ্তসার:

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

হালনাগাদ

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

Question 4

আমার দৃষ্টিকোণটি হ'ল:

অ্যানিমিক ডোমেন মডেল = ডাটাবেস টেবিলগুলি বস্তুগুলিতে ম্যাপ করা হয়েছে (কেবলমাত্র ক্ষেত্রের মান, আসল আচরণ নয়)

সমৃদ্ধ ডোমেন মডেল = আচরণ প্রকাশ করে এমন বস্তুর সংকলন

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

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

Question 5

প্রথমত, আমি এই নিবন্ধটি থেকে উত্তরগুলি অনুলিপি করেছি http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx

চিত্র 1 এনেমিক ডোমেন মডেল দেখায় যা মূলত গেটার্স এবং সেটটারগুলির সাথে একটি স্কিমা।

Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables

public class Customer : Person
{
  public Customer()
  {
    Orders = new List<Order>();
  }
  public ICollection<Order> Orders { get; set; }
  public string SalesPersonId { get; set; }
  public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string CompanyName { get; set; }
  public string EmailAddress { get; set; }
  public string Phone { get; set; }
}

এই সমৃদ্ধ মডেলটিতে, পড়ার এবং লিখিত হওয়ার জন্য বৈশিষ্ট্যগুলি কেবল প্রকাশ করার পরিবর্তে গ্রাহকের সার্বজনীন পৃষ্ঠটি স্পষ্ট পদ্ধতিতে গঠিত।

Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties

public class Customer : Contact
{
  public Customer(string firstName, string lastName, string email)
  {
    FullName = new FullName(firstName, lastName);
    EmailAddress = email;
    Status = CustomerStatus.Silver;
  }
  internal Customer()
  {
  }
  public void UseBillingAddressForShippingAddress()
  {
    ShippingAddress = new Address(
      BillingAddress.Street1, BillingAddress.Street2,
      BillingAddress.City, BillingAddress.Region,
      BillingAddress.Country, BillingAddress.PostalCode);
  }
  public void CreateNewShippingAddress(string street1, string street2,
   string city, string region, string country, string postalCode)
  {
    ShippingAddress = new Address(
      street1,street2,
      city,region,
      country,postalCode)
  }
  public void CreateBillingInformation(string street1,string street2,
   string city,string region,string country, string postalCode,
   string creditcardNumber, string bankName)
  {
    BillingAddress = new Address      (street1,street2, city,region,country,postalCode );
    CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
  }
  public void SetCustomerContactDetails
   (string email, string phone, string companyName)
  {
    EmailAddress = email;
    Phone = phone;
    CompanyName = companyName;
  }
  public string SalesPersonId { get; private set; }
  public CustomerStatus Status { get; private set; }
  public Address ShippingAddress { get; private set; }
  public Address BillingAddress { get; private set; }
  public CustomerCreditCard CreditCard { get; private set; }
}

Question 6

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

আচরণ সহ ডোমেন শ্রেণীর উদাহরণ:

class Order {

     String number

     List<OrderItem> items

     ItemList bonus

     Delivery delivery

     void addItem(Item item) { // add bonus if necessary }

     ItemList needToDeliver() { // items + bonus }

     void deliver() {
         delivery = new Delivery()
         delivery.items = needToDeliver()
     }

}

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

মতামত জবাব

আমি নিয়ামক থেকে ডোমেন ক্লাসটি এভাবে ব্যবহার করি:

def save = {
   Order order = new Order()
   order.addItem(new Item())
   order.addItem(new Item())
   repository.create(order)
}

এর সৃষ্টি Orderএবং এর LineItemএকটি লেনদেন হয়। এর মধ্যে যদি একটি LineItemতৈরি করা না যায় তবে কোনওটি তৈরি করা Orderহবে না।

আমার কাছে এমন পদ্ধতি রয়েছে যা একটি একক লেনদেনের প্রতিনিধিত্ব করে, যেমন:

def deliver = {
   Order order = repository.findOrderByNumber('ORDER-1')
   order.deliver()       
   // save order if necessary
}

ভিতরে থাকা যেকোনো কিছুই deliver()একক লেনদেন হিসাবে কার্যকর করা হবে। আমার যদি একটি একক লেনদেনে অনেকগুলি সম্পর্কযুক্ত পদ্ধতি সম্পাদন করতে হয় তবে আমি একটি পরিষেবা শ্রেণি তৈরি করব।

অলস লোডিং ব্যতিক্রম এড়াতে, আমি জেপিএ ২.১ নামের সত্তা গ্রাফ ব্যবহার করি। উদাহরণস্বরূপ, বিতরণ স্ক্রিনের জন্য নিয়ামক হিসাবে, আমি deliveryবৈশিষ্ট্য লোড করার পদ্ধতি তৈরি করতে পারি এবং উপেক্ষা করতে পারি bonus, যেমন repository.findOrderByNumberFetchDelivery()। বোনাস স্ক্রিনে, আমি অন্য একটি পদ্ধতি কল করি যা bonusবৈশিষ্ট্য লোড করে এবং উপেক্ষা করে delivery, যেমন repository.findOrderByNumberFetchBonus()। এটির জন্য ডিসপ্লাইন দরকার কারণ আমি এখনও deliver()বোনাস স্ক্রিনের ভিতরে কল করতে পারি না ।

Question 7

যখন আমি একচেটিয়া ডেস্কটপ অ্যাপ্লিকেশন লিখতাম যখন আমি সমৃদ্ধ ডোমেন মডেলগুলি তৈরি করি, সেগুলি তৈরি করে উপভোগ করতাম।

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

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

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

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

একটি বৃহত্তর আরও একতরফা একক (মাইক্রো) পরিষেবা, বিশেষত এটি যে এটি র‍্যামে মডেল রাখে, ডিডিডি থেকে উপকৃত হতে পারে।

Question 8

আমি মনে করি সমস্যার মূলটি মিথ্যা দ্বৈতত্ত্বের মধ্যে রয়েছে। এই 2 টি মডেল কীভাবে পাওয়া যাবে: সমৃদ্ধ এবং "রক্তাল্প" এবং একে অপরের সাথে বিপরীত করা সম্ভব? আমি মনে করি এটি কেবল তখনই সম্ভব যখন আপনি কোন শ্রেণিটি সম্পর্কে কোনও ভুল ধারণা রাখেন । আমি নিশ্চিত নই, তবে আমি মনে করি এটি ইউটিউবের বোঝিদার বোজনভের একটি ভিডিওতে পেয়েছি। একটি শ্রেণি এই ডেটা উপর একটি ডেটা + পদ্ধতি নয়। এটি সম্পূর্ণরূপে অবৈধ বোঝাপড়া যা ক্লাসগুলিকে দুটি বিভাগে বিভক্ত করে: কেবলমাত্র ডেটা, তাই রক্তাল্পতা মডেল এবং ডেটা + পদ্ধতি - এত সমৃদ্ধ মডেল (আরও সঠিকভাবে একটি তৃতীয় বিভাগ রয়েছে: পদ্ধতিগুলি এমনকি এমনকি)।

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

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

সুতরাং, আমরা অন্য শ্রেণিতে যুক্তি বের করতে পারি এবং মূল একটিতে ডেটা ছেড়ে যেতে পারি, তবে এটি উপলব্ধি করে না কারণ কিছু ধারণায় বৈশিষ্ট্য এবং সম্পর্ক / প্রক্রিয়া / পদ্ধতিগুলি অন্তর্ভুক্ত থাকতে পারে এবং সেগুলির একটি পৃথকীকরণ 2 নামের অধীনে ধারণাকে নকল করবে যা হতে পারে নিদর্শনগুলিতে হ্রাস করা হয়েছে: "OBJECT- গুণাবলী" এবং "OBJECT-যুক্তি"। প্রক্রিয়াজাতীয় এবং কার্যকরী ভাষাগুলিতে তাদের সীমাবদ্ধতার কারণে এটি ঠিক আছে তবে এটি এমন ভাষার জন্য অত্যধিক স্ব-সংযম যা আপনাকে সমস্ত ধরণের ধারণাকে বর্ণনা করতে দেয়।

Question 9

অ্যানিমিক ডোমেন মডেলগুলি ওআরএম এবং নেটওয়ার্কগুলির উপর সহজ ট্রান্সফারের জন্য গুরুত্বপূর্ণ (সমস্ত কৌতুকাল অ্যাপ্লিকেশনের প্রাণ-রক্ত) তবে ওও আপনার কোডের 'ট্রানজেকশনাল / হ্যান্ডলিং' অংশগুলি এনক্যাপসুলেশন এবং সহজ করার জন্য খুব গুরুত্বপূর্ণ important

অতএব যা গুরুত্বপূর্ণ তা হ'ল একটি বিশ্ব থেকে অন্য বিশ্বকে চিহ্নিত করতে এবং রূপান্তর করতে সক্ষম।

অ্যানিমিক মডেলগুলির নাম অ্যানিমিউসার, বা ইউজারডাও ইত্যাদি ইত্যাদির নাম রাখুন যাতে বিকাশকারীরা জানেন যে ব্যবহারের জন্য আরও ভাল বর্গ রয়েছে, তবে অ্যানিমিক শ্রেণীর জন্য উপযুক্ত কনস্ট্রাক্টর নেই

User(AnemicUser au)

এবং পরিবহন / অধ্যবসায়ের জন্য অ্যানিমিক শ্রেণি তৈরি করার জন্য অ্যাডাপ্টার পদ্ধতি

User::ToAnemicUser()

পরিবহন / অধ্যবসায়ের বাইরে যে কোনও জায়গায় অ্যানিমিক ব্যবহারকারী ব্যবহার করার লক্ষ্য নেই

Question 10

এখানে একটি উদাহরণ যা সাহায্য করতে পারে:

অ্যানিমিক

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

অ-রক্তাল্পতা

class Box
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int area()
    {
       return Height * Width;
    }
}

Question 11

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

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

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