আমি এমন একটি প্রকল্পে কাজ করছি যেখানে আমরা পরিষেবা-ভিত্তিক আর্কিটেকচারে ডোমেন-চালিত নকশা এবং REST উভয়ই প্রয়োগ করার চেষ্টা করছি। আমরা প্রায় 100% আরএসটি কমপ্লায়েন্স নিয়ে চিন্তা করছি না; এটি সম্ভবত বলা ভাল যে আমরা রিসোর্স-ওরিয়েন্টেড এইচটিটিপি এপিআই (~ রিচার্ডসনের আরইএসটি পরিপক্কতার মডেলের স্তর 2 ) তৈরি করার চেষ্টা করছি। তা সত্ত্বেও, আমরা HTTP অনুরোধের আরপিসি-শৈলী ব্যবহার থেকে দূরে থাকতে চেষ্টা করছেন, অর্থাত আমরা বাস্তবায়ন করার প্রচেষ্টা আমাদের HTTP- র ক্রিয়া অনুযায়ী RFC2616 বরং ব্যবহার না করে POSTকরতে IsPostalAddressValid(...)উদাহরণস্বরূপ,।
যাইহোক, এর উপর জোর দেওয়া ডোমেন-চালিত ডিজাইন প্রয়োগের আমাদের প্রয়াসের ব্যয় বলে মনে হচ্ছে। শুধুমাত্র সঙ্গে GET, POST, PUT, DELETEএবং কয়েক অন্যান্য কদাচিৎ ব্যবহৃত পদ্ধতি, আমরা CRUDdy সেবা নির্মাণ ঝোঁক, এবং CRUDdy সেবা রক্তহীন ডোমেইন মডেল আছে ঝোঁক।
POST: ডেটা গ্রহণ করুন, এটি যাচাই করুন, ডেটাতে ফেলে দিন। GET: তথ্য পুনরুদ্ধার করুন, এটি ফেরত দিন। কোনও আসল ব্যবসায়ের যুক্তি নেই। আমরা পরিষেবাগুলির মধ্যে বার্তা (ইভেন্টগুলি )ও ব্যবহার করি এবং আমার কাছে মনে হয় যে বেশিরভাগ ব্যবসায়িক যুক্তিই এর চারপাশে তৈরি হওয়া শেষ করে।
কোনও পর্যায়ে কি রিস্ট এবং ডিডিডি উত্তেজনা রয়েছে? (বা আমি কি এখানে কিছু ভুল বোঝাবুঝি করছি? আমরা সম্ভবত অন্য কিছু ভুল করছি?) আরপিসি-স্টাইলের এইচটিটিপি কলগুলি এড়িয়ে গিয়ে পরিষেবা-ভিত্তিক আর্কিটেকচারে একটি শক্তিশালী ডোমেন মডেল তৈরি করা কি সম্ভব?