সমৃদ্ধ ডোমেন মডেলগুলি - আচরণের সাথে কীভাবে ঠিক ফিট হয়?


84

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

বাস্তব-বিশ্বের উদাহরণের জন্য, ডিডিডি-র এই প্রয়োগটি ভুল বলে মনে হচ্ছে:

নীচের ওয়ার্ক আইটেম ডোমেন মডেলগুলি সম্পত্তি-ব্যাগ ব্যতীত কিছুই নয়, কোনও কোড-প্রথম ডাটাবেসের জন্য সত্তা ফ্রেমওয়ার্ক দ্বারা ব্যবহৃত হয়। প্রতি ফওলার, এটি রক্তাল্পতা

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

সুতরাং নীচেরটি যদি ভুল হয় তবে আমি কীভাবে এটি সঠিক করতে পারি?
আচরণ, যেমন অ্যাডস্ট্যাটাসআপডেট বা চেকআউট , ওয়ার্ক আইটেম শ্রেণীর অন্তর্ভুক্ত হওয়া উচিত?
ওয়ার্কআইটেম মডেলটির কী নির্ভরতা থাকা উচিত?

এখানে চিত্র বর্ণনা লিখুন

public class WorkItemService : IWorkItemService {
    private IUnitOfWorkFactory _unitOfWorkFactory;

    //using Unity for dependency injection
    public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) {
        _unitOfWorkFactory = unitOfWorkFactory;
    }

    public void AddStatusUpdate(int workItemId, int statusId) {

        using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) {
            var workItemRepo = unitOfWork.WorkItemRepository;
            var workItemStatusRepo = unitOfWork.WorkItemStatusRepository;

            var workItem = workItemRepo.Read(wi => wi.Id == workItemId).FirstOrDefault();
            if (workItem == null)
                throw new ArgumentException(string.Format(@"The provided WorkItem Id '{0}' is not recognized", workItemId), "workItemId");

            var status = workItemStatusRepo.Read(s => s.Id == statusId).FirstOrDefault();
            if (status == null)
                throw new ArgumentException(string.Format(@"The provided Status Id '{0}' is not recognized", statusId), "statusId");

            workItem.StatusHistory.Add(status);

            workItemRepo.Update(workItem);
            unitOfWork.Save();
        }
    }
}

(এই উদাহরণটি আরও পঠনযোগ্য হওয়ার জন্য সহজতর করা হয়েছিল The কোডটি অবশ্যই বিশৃঙ্খলাযুক্ত, কারণ এটি একটি বিভ্রান্ত প্রচেষ্টা but কেবল CRUD দ্বারা পরিচালিত হতে পারে))

হালনাগাদ

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

আপডেট - 2 বছর পরে

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

এখানে চিত্র বর্ণনা লিখুন

আমি এখনও এই (খুব সক্রিয়) পোস্টে যে কোনও বৈধ ডোমেন মডেলের জন্য যে কোনও সেরা-অনুশীলন কোড সরবরাহ করে এমন কোনও উত্তরকে স্বাগত জানাই।


6
সমস্ত দার্শনিক তত্ত্বগুলি যখন আপনি তাদের বলবেন ঠিক তখনই মাটিতে পড়ে যান "I don't want to duplicate all my entities into DTOs simply because I don't need it and it violates DRY, and I also don't want my client application to take a dependency on EntityFramework.dll"। সত্তা ফ্রেমওয়ার্ক জারগনে "সত্তা" "ডোমেন মডেল" এর মতো "সত্তা" হিসাবে একই নয়
ফেডেরিকো বেরাসেটুই

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

16
আমি জিমি Bogard এর এনডিসি 2012 অধিবেশন দেখার জন্য এ "দুষ্ট ডোমেন মডেল ক্রাফ্টিং" আপনি সুপারিশ করবে Vimeo । তিনি ব্যাখ্যা করেছেন যে সমৃদ্ধ ডোমেনটি কী হওয়া উচিত এবং কীভাবে আপনার সত্তাগুলিতে আচরণ করে তাদের বাস্তব জীবনে প্রয়োগ করা যায়। উদাহরণগুলি খুব ব্যবহারিক এবং সমস্ত সি # তে রয়েছে।
আলেক্সি জিমেরেভ

আপনাকে ধন্যবাদ, আমি ভিডিওটির অর্ধেক পথ পেরিয়ে এসেছি এবং এটি এখনও অবধি নিখুঁত। আমি জানতাম যে এটি যদি ভুল হয় তবে কোথাও কোথাও একটি "সঠিক" উত্তর থাকতে হবে ....
আরজেবি

2
আমি জাভার প্রতিও ভালবাসার দাবি করছি: /
uylmz

উত্তর:


59

সবচেয়ে সহায়ক উত্তর আলেক্সি জিমেরেভ দিয়েছিলেন এবং একজন মডারেটর আমার মূল প্রশ্নের নীচে একটি মন্তব্যে স্থানান্তরিত করার আগে কমপক্ষে 7 টি আপগেট পেয়েছিল ...

তার উত্তর:

আমি আপনাকে জিমি বোগার্ডের এনডিসি 2012 সেশনের ভিমেওতে "ক্রাইফটিং উইকড ডোমেন মডেলগুলি" দেখার পরামর্শ দিচ্ছি। তিনি ব্যাখ্যা করেছেন যে সমৃদ্ধ ডোমেনটি কী হওয়া উচিত এবং কীভাবে আপনার সত্তাগুলিতে আচরণ করে তাদের বাস্তব জীবনে প্রয়োগ করা যায়। উদাহরণগুলি খুব ব্যবহারিক এবং সমস্ত সি # তে রয়েছে।

http://vimeo.com/43598193

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

  • "বেশিরভাগ অ্যাপ্লিকেশনগুলির জন্য ... আমরা জানি না যে আমরা শুরু করার সাথে সাথে তারা জটিল হতে চলেছে They তারা কেবল সেভাবেই পরিণত হয়।"
    • কোড এবং প্রয়োজনীয়তা যুক্ত হওয়ার সাথে সাথে জটিলতা স্বাভাবিকভাবেই বৃদ্ধি পায়। অ্যাপ্লিকেশনগুলি CRUD হিসাবে খুব সহজভাবে শুরু করতে পারে তবে আচরণ / নিয়মগুলি বেকড হয়ে যেতে পারে।
    • "সুন্দর জিনিসটি হ'ল আমাদের জটিলতা শুরু করতে হবে না We আমরা রক্তস্বল্প ডোমেন মডেল দিয়ে শুরু করতে পারি, এটি কেবল সম্পত্তি ব্যাগ এবং কেবলমাত্র স্ট্যান্ডার্ড রিফ্যাক্টরিং কৌশল দিয়ে আমরা একটি সত্যিকারের ডোমেন মডেলের দিকে যেতে পারি।"
  • ডোমেন মডেল = ব্যবসায়িক অবজেক্ট। ডোমেন আচরণ = ব্যবসায়ের নিয়ম।
  • আচরণটি প্রায়শই কোনও অ্যাপ্লিকেশনটিতে লুকানো থাকে - এটি পেজলড, বাটন 1_ ক্লিক বা অনেক ক্ষেত্রে 'ফুম্যানেজার' বা 'ফস সার্ভিস' এর মতো সহায়ক শ্রেণিতে থাকতে পারে।
  • ডোমেন অবজেক্ট থেকে পৃথক ব্যবসায়ের বিধিগুলি সেই নিয়মগুলিকে "আমাদের মনে রাখা দরকার"।
    • উপরে আমার ব্যক্তিগত উদাহরণে, একটি ব্যবসার নিয়ম হ'ল ওয়ার্ক আইটেম at স্ট্যাটাস হিস্টোরি.এড ()। আমরা কেবল স্থিতি পরিবর্তন করছি না, আমরা এটি নিরীক্ষণের জন্য সংরক্ষণাগারভুক্ত করছি।
  • ডোমেন আচরণগুলি "একটি গুচ্ছ পরীক্ষার চেয়ে অনেক বেশি সহজেই অ্যাপ্লিকেশনটিতে বাগগুলি নির্মূল করে" " টেস্টগুলির জন্য আপনাকে সেই পরীক্ষাগুলি লিখতে হবে। ডোমেন আচরণগুলি আপনাকে পরীক্ষার সঠিক পথ সরবরাহ করে
  • ডোমেন পরিষেবাগুলি হ'ল "বিভিন্ন ডোমেন মডেল সত্তার মধ্যে ক্রিয়াকলাপ সমন্বয় করতে সহায়ক শ্রেণি।"
    • ডোমেন পরিষেবা! = ডোমেন আচরণ। সত্তাগুলি আচরণ করে, ডোমেন পরিষেবাগুলি সত্ত্বার মধ্যে কেবল মধ্যস্থতাকারী।
  • ডোমেন অবজেক্টগুলির তাদের প্রয়োজনীয় অবকাঠামোগুলির দখল থাকা উচিত নয় (যেমন আইওফারক্যালকুলেটর সার্ভিস)। অবকাঠামোগত পরিষেবাটি এটি ব্যবহার করে এমন ডোমেন মডেলের কাছে যেতে হবে।
  • ডোমেন মডেলগুলিকে তারা কী করতে পারে তা আপনাকে বলার জন্য অফার করা উচিত এবং তাদের কেবল সেগুলি করতে সক্ষম হওয়া উচিত।
  • ডোমেন মডেলগুলির বৈশিষ্ট্যগুলি প্রাইভেট সেটারগুলির সাহায্যে রক্ষা করা উচিত, যাতে কেবল মডেল তার নিজস্ব আচরণগুলি ব্যবহার করে নিজস্ব বৈশিষ্ট্য নির্ধারণ করতে পারে । অন্যথায় এটি "প্রতারণামূলক" "
  • অ্যানিমিক ডোমেন মডেল অবজেক্টগুলি, যা কোনও ওআরএমের জন্য কেবল সম্পত্তি ব্যাগ, কেবল "একটি পাতলা ব্যহ্যাবরণ - ডাটাবেসের উপরে দৃ strongly়ভাবে টাইপিত সংস্করণ" "
    • "তবে কোনও অবজেক্টে ডাটাবেস সারি পাওয়া সহজ তবে আমরা পেয়েছি" "
    • 'বেশিরভাগ ধৈর্যশীল বস্তুর মডেলগুলি কেবল এটিই। কোনও অ্যানিমিক ডোমেন মডেলকে বনাম এমন একটি অ্যাপ্লিকেশন বনাম যা সত্যই আচরণ করে না এমনটি যদি কোনও বস্তুর ব্যবসায়ের নিয়ম থাকে তবে সেগুলি নিয়ম কোনও ডোমেন মডেলটিতে পাওয়া যায় না। '
  • "প্রচুর অ্যাপ্লিকেশনগুলির জন্য, কোনও ধরণের বাস্তব ব্যবসায়িক প্রয়োগের যুক্তিযুক্ত স্তর তৈরি করার দরকার নেই, এটি কেবলমাত্র ডেটাবেসের সাথে কথা বলতে পারে এবং সম্ভবত সেখানে উপস্থিত ডেটার উপস্থাপনের কিছু সহজ উপায়।"
    • সুতরাং অন্য কথায়, আপনি যা করছেন তা যদি কোনও নির্দিষ্ট ব্যবসায়িক জিনিস বা আচরণের বিধিবিহীন CRUD হয় তবে আপনার ডিডিডি লাগবে না।

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


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

6

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

উদাহরণস্বরূপ, যদি প্রয়োজন হয় যে কোনও নির্দিষ্ট কাজের আইটেমের কেবলমাত্র নির্দিষ্ট স্ট্যাটাস থাকতে পারে, বা এটিতে কেবলমাত্র এন স্ট্যাটাস থাকতে পারে, তবে তা ডোমেন যুক্তিযুক্ত এবং এটি উভয়ই WorkItemবা StatusHistoryকোনও পদ্ধতি হিসাবে হওয়া উচিত ।

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

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

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


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

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

5

আপনার অনুমান যে আপনার ব্যবসায়ের যুক্তিটিকে ওয়ার্ক আইটেমের সাথে "ফ্যাট পরিষেবা" -র সাথে যুক্ত করে তোলে এমন একটি অন্তর্নিহিত বিরোধী ধাঁচ যা আমি তর্ক করব এটি অগত্যা নয়।

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

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

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


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

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

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

@ স্টেফানবিলিয়েট একটি নিখুঁত বিশ্বে আমি আপনার সাথে একমত হই যেখানে কোনও ব্যবসায়ী বিশেষজ্ঞের বিকাশকারীদের সাথে বসার সময় রয়েছে। সফ্টওয়্যার শিল্পের বাস্তবতা হ'ল এই ব্যবসায়িক বিশেষজ্ঞের এই স্তরে জড়িত হওয়ার বা তার চেয়ে খারাপ সময় বা আগ্রহ বাধা নেই তবুও বিকাশকারীরা কেবল অস্পষ্ট গাইডেন্স দিয়েই এটি নির্ধারণ করবেন বলে আশা করা হচ্ছে।
ম্যাপেল_শ্যাফ্ট

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

5

আমি বুঝতে পারি এই প্রশ্নটি বেশ পুরানো তাই উত্তরটি উত্তরোত্তর জন্য। আমি তত্ত্বের উপর ভিত্তি করে একটি স্থির উদাহরণ দিয়ে উত্তর দিতে চাই।

WorkItemক্লাসে "কাজের আইটেমের স্থিতি পরিবর্তন করা" এর মতো করে নিযুক্ত করুন :

public SomeStatusUpdateType Status { get; private set; }

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Maybe we designed this badly at first ;-)
    Status = status;       
}

এখন আপনার WorkItemশ্রেণি একটি আইনী রাষ্ট্রে নিজেকে বজায় রাখার জন্য দায়বদ্ধ। তবে বাস্তবায়ন বেশ দুর্বল। পণ্যটির মালিকের কাছে করা সমস্ত স্থিতি আপডেটের ইতিহাস চায় WorkItem

আমরা এটিকে এমন কিছুতে পরিবর্তন করি:

private ICollection<SomeStatusUpdateType> StatusUpdates { get; private set; }
public SomeStatusUpdateType Status => StatusUpdates.OrderByDescending(s => s.CreatedOn).FirstOrDefault();

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Better...
    StatusUpdates.Add(status);       
}

বাস্তবায়ন মারাত্মকভাবে পরিবর্তিত হয়েছে তবে ChangeStatusপদ্ধতির কলকারী অন্তর্নিহিত বাস্তবায়ন বিবরণ সম্পর্কে অজানা এবং নিজের পরিবর্তনের কোনও কারণ নেই।

এটি সমৃদ্ধ ডোমেন মডেল সত্তা, আইএমএইচওর একটি উদাহরণ।

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