डीडीडी की कुछ अवधारणाओं को वास्तविक कोड में कैसे लागू किया जाए? अंदर विशिष्ट प्रश्न

Question

मैं DDD का अध्ययन कर रहा हूं और वर्तमान में मैं वास्तविक कोड में अवधारणाओं को लागू करने का तरीका खोजने के लिए संघर्ष कर रहा हूं। मेरे पास एन-टियर के साथ लगभग 10 साल का अनुभव है, इसलिए यह बहुत संभावना है कि मैं जिस कारण से संघर्ष कर रहा हूं, वह यह है कि मेरा मानसिक मॉडल उस डिजाइन से बहुत अधिक जुड़ा हुआ है।

मैंने एक Asp.NET वेब अनुप्रयोग बनाया है और मैं एक साधारण डोमेन के साथ शुरू कर रहा हूँ: एक वेब निगरानी अनुप्रयोग। आवश्यकताएँ:

• उपयोगकर्ता को मॉनिटर करने के लिए एक नया वेब ऐप पंजीकृत करने में सक्षम होना चाहिए। वेब ऐप में एक URL के लिए एक अनुकूल नाम और अंक हैं;
• वेब ऐप समय-समय पर एक स्थिति (ऑनलाइन / ऑफ़लाइन) के लिए मतदान करेगा;
• वेब ऐप समय-समय पर अपने वर्तमान संस्करण के लिए सर्वेक्षण करेगा (वेब ​​ऐप में "/version.html" होने की उम्मीद है, जो एक विशिष्ट मार्कअप में अपने सिस्टम संस्करण की घोषणा करने वाली फ़ाइल है)।

मेरी शंका मुख्य रूप से जिम्मेदारियों के बंटवारे की चिंता है, प्रत्येक चीज़ के लिए उचित स्थान (सत्यापन, व्यावसायिक नियम, आदि) का पता लगाना। नीचे, मैंने कुछ कोड और प्रश्न और विचार के साथ टिप्पणियाँ लिखी हैं।

कृपया आलोचना करें और सलाह दें । अग्रिम में धन्यवाद!

---

DOMAIN मॉडल

सभी व्यावसायिक नियमों को ध्वस्त करने के लिए प्रतिरूपित किया गया।

// Encapsulates logic for creating and validating Url's.
// Based on "Unbreakable Domain Models", YouTube talk from Mathias Verraes
// See https://youtu.be/ZJ63ltuwMaE
public class Url: ValueObject
{
    private System.Uri _uri;

    public string Url => _uri.ToString();

    public Url(string url)
    {
        _uri = new Uri(url, UriKind.Absolute); // Fails for a malformed URL.
    }
}

// Base class for all Aggregates (root or not).
public abstract class Aggregate
{
    public Guid Id { get; protected set; } = Guid.NewGuid();
    public DateTime CreatedAt { get; protected set; } = DateTime.UtcNow;
}

public class WebApp: Aggregate
{
    public string Name { get; private set; }
    public Url Url { get; private set; }
    public string Version { get; private set; }
    public DateTime? VersionLatestCheck { get; private set; }
    public bool IsAlive { get; private set; }
    public DateTime? IsAliveLatestCheck { get; private set; }

    public WebApp(Guid id, string name, Url url)
    {
        if (/* some business validation fails */)
            throw new InvalidWebAppException(); // Custom exception.

        Id = id;
        Name = name;
        Url = url;
    }

    public void UpdateVersion()
    {
        // Delegates the plumbing of HTTP requests and markup-parsing to infrastructure.
        var versionChecker = Container.Get<IVersionChecker>();
        var version = versionChecker.GetCurrentVersion(this.Url);

        if (version != this.Version)
        {
            var evt = new WebAppVersionUpdated(
                this.Id, 
                this.Name, 
                this.Version /* old version */, 
                version /* new version */);
            this.Version = version;
            this.VersionLatestCheck = DateTime.UtcNow;

            // Now this eems very, very wrong!
            var repository = Container.Get<IWebAppRepository>();
            var updateResult = repository.Update(this);
            if (!updateResult.OK) throw new Exception(updateResult.Errors.ToString());

            _eventDispatcher.Publish(evt);
        }

        /*
         * I feel that the aggregate should be responsible for checking and updating its
         * version, but it seems very wrong to access a Global Container and create the
         * necessary instances this way. Dependency injection should occur via the
         * constructor, and making the aggregate depend on infrastructure also seems wrong.
         * 
         * But if I move such methods to WebAppService, I'm making the aggregate
         * anaemic; It will become just a simple bag of getters and setters.
         *
         * Please advise.
         */
    }

    public void UpdateIsAlive()
    {
        // Code very similar to UpdateVersion().
    }
}

और Creates और Deletes को संभालने के लिए एक DomainService क्लास, जो मेरा मानना ​​है कि केवल Aggregate की चिंता नहीं है।

public class WebAppService
{
    private readonly IWebAppRepository _repository;
    private readonly IUnitOfWork _unitOfWork;
    private readonly IEventDispatcher _eventDispatcher;

    public WebAppService(
        IWebAppRepository repository, 
        IUnitOfWork unitOfWork, 
        IEventDispatcher eventDispatcher
    ) {
        _repository = repository;
        _unitOfWork = unitOfWork;
        _eventDispatcher = eventDispatcher;
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        var webApp = new WebApp(newWebApp);

        var addResult = _repository.Add(webApp);
        if (!addResult.OK) return addResult.Errors;

        var commitResult = _unitOfWork.Commit();
        if (!commitResult.OK) return commitResult.Errors;

        _eventDispatcher.Publish(new WebAppRegistered(webApp.Id, webApp.Name, webApp.Url);
        return OperationResult.Success;
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        var removeResult = _repository.Remove(webAppId);
        if (!removeResult) return removeResult.Errors;

        _eventDispatcher.Publish(new WebAppRemoved(webAppId);
        return OperationResult.Success;
    }
}

---

अनुप्रयोग परत

नीचे दी गई श्रेणी WebMonitoring डोमेन के लिए बाहरी दुनिया (वेब ​​इंटरफेस, बाकी एपीआई, आदि) के लिए एक इंटरफ़ेस प्रदान करती है। यह इस समय केवल एक शेल है, उपयुक्त सेवाओं के लिए पुर्ननिर्देशित करता है, लेकिन यह भविष्य में और अधिक तर्क (हमेशा डोमेन मॉडल के माध्यम से पूरा) को ऑर्केस्ट्रेट करने के लिए बढ़ेगा।

public class WebMonitoringAppService
{
    private readonly IWebAppQueries _webAppQueries;
    private readonly WebAppService _webAppService;

    /*
     * I'm not exactly reaching for CQRS here, but I like the idea of having a
     * separate class for handling queries right from the beginning, since it will
     * help me fine-tune them as needed, and always keep a clean separation between
     * crud-like queries (needed for domain business rules) and the ones for serving
     * the outside-world.
     */

    public WebMonitoringAppService(
        IWebAppQueries webAppQueries, 
        WebAppService webAppService
    ) {
        _webAppQueries = webAppQueries;
        _webAppService = webAppService;
    }

    public WebAppDetailsDto GetDetails(Guid webAppId)
    {
        return _webAppQueries.GetDetails(webAppId);
    }

    public List<WebAppDetailsDto> ListWebApps()
    {
        return _webAppQueries.ListWebApps(webAppId);
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        return _webAppService.RegisterWebApp(newWebApp);
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        return _webAppService.RemoveWebApp(newWebApp);
    }
}

---

मामले को बंद करना

यहाँ और इस अन्य प्रश्न के उत्तर को इकट्ठा करने के बाद , जिसे मैंने एक अलग कारण से खोला लेकिन अल्टिमेटली को इस बिंदु के समान ही मिला, मैं इस क्लीनर और बेहतर समाधान के साथ आया:

Github Gist में समाधान प्रस्ताव

Comments

मैं बहुत कुछ पढ़ रहा हूं, लेकिन मुझे ऐसे व्यावहारिक उदाहरण नहीं मिले हैं, सिवाय सीक्यूआरएस और अन्य ओर्थोगोनल पैटर्न और प्रथाओं को लागू करने वाले लोगों के अलावा, लेकिन मैं अभी इस सरल चीज की तलाश कर रहा हूं।

— लेविदाद

यह सवाल codereview.stackexchange.com लिए बेहतर विकल्प हो सकता है

— VoiceOfUnreason

मैं स्वयं आपको बहुत समय के साथ n-tier ऐप के साथ बिताता हूं। मुझे केवल पुस्तकों, मंचों आदि से ही DDD के बारे में पता है, इसलिए मैं केवल एक टिप्पणी पोस्ट करूंगा। सत्यापन दो प्रकार के होते हैं: इनपुट सत्यापन और व्यावसायिक नियम सत्यापन। इनपुट सत्यापन एप्लिकेशन परत में जाता है और डोमेन सत्यापन डोमेन लेयर में जाता है। WebApp एक निकाय की तरह अधिक दिखता है और एक Aggreagate नहीं है और WebAppService एक डोमेन सेवा की तुलना में एप्लिकेशन सेवा की तरह अधिक दिखता है। इसके अलावा आपके समग्र कंटेनर का संदर्भ देते हैं जो एक बुनियादी ढांचा है। यह एक सर्विस लोकेटर की तरह भी दिखता है।

— एड्रियन इफोडे

हां, क्योंकि यह कोई संबंध नहीं बनाता है। एग्रीगेट डोमेन ऑब्जेक्ट्स के बीच संबंधों को मॉडलिंग कर रहे हैं। WebApp में केवल कच्चा डेटा और कुछ व्यवहार है और उदाहरण के लिए निम्नलिखित इनवेरिएंट के साथ सौदा हो सकता है: पागल जैसे संस्करणों को अद्यतन करने के लिए ठीक नहीं है अर्थात जब मौजूदा संस्करण 1 है, तो संस्करण 3 का

— चरण

जब तक ValueObject के पास एक तरीका है जो उदाहरणों के बीच समानता को लागू करता है, मुझे लगता है कि यह ठीक है। अपने परिदृश्य में आप एक संस्करण मान ऑब्जेक्ट बना सकते हैं। सिमेंटिक वर्जनिंग की जाँच करें, आपको इस बारे में बहुत सारे विचार मिलेंगे कि आप इस वैल्यू ऑब्जेक्ट को कैसे मॉडल कर सकते हैं, जिसमें इन्वेंट्री और व्यवहार शामिल हैं। WebApp को एक रिपॉजिटरी से बात नहीं करनी चाहिए, वास्तव में मेरा मानना ​​है कि आपके प्रोजेक्ट से ऐसा कोई संदर्भ नहीं है जिसमें आधारभूत संरचना (रिपॉजिटरी, काम की इकाई) से संबंधित किसी भी चीज़ का डोमेन सामान या तो प्रत्यक्ष या अप्रत्यक्ष रूप से (इंटरफेस के माध्यम से) हो।

— एड्रियन इफोडे

Answer 1

आपके WebAppएग्रीगेट पर सलाह की एक लंबी लाइन , मैं पूरी तरह से सहमत हूं कि इसमें खींचना repositoryसही दृष्टिकोण नहीं है। मेरे अनुभव में, एग्रीगेट 'निर्णय' करेगा कि क्या कोई कार्रवाई ठीक है या नहीं यह उसके अपने राज्य पर आधारित है। इस प्रकार राज्य पर नहीं यह अन्य सेवाओं से खींच सकता है। यदि आपको इस तरह के चेक की आवश्यकता होगी, तो मैं आम तौर पर उस सेवा की ओर बढ़ूंगा जो समग्र (आपके उदाहरण में WebAppService) को कॉल करता है ।

इसके अतिरिक्त, आप उपयोग के मामले में उतर सकते हैं कि कई अनुप्रयोग समवर्ती अपने समुच्चय को कॉल करना चाहते हैं। यदि ऐसा होता है, जबकि आप इस तरह से आउटबाउंड कॉल कर रहे हैं, जिसमें आपको लंबा समय लग सकता है, तो आप इस प्रकार अन्य योगों के लिए अपने कुल को रोक रहे हैं। यह अंततः कुल-हैंडलिंग को धीमा कर देगा, जो मुझे लगता है कि कुछ भी वांछनीय नहीं है।

इसलिए हालांकि ऐसा लग सकता है कि आपका एग्रीगेट काफी पतला हो जाता है यदि आप उस सत्यापन को थोड़ा आगे बढ़ाते हैं, तो मुझे लगता है कि इसे स्थानांतरित करना बेहतर है WebAppService।

मैं यह भी सुझाव दूंगा कि आप इस WebAppRegisteredघटना के प्रकाशन को अपने कुल में ले जाएं। एग्रीगेट वह लड़का है जिसे बनाया जा रहा है, इसलिए यदि यह निर्माण प्रक्रिया सफल होती है, तो यह समझ में आता है कि वह दुनिया को उस नॉलेजड को प्रकाशित करने दे।

आशा है कि यह आपकी मदद करता है @Levidad!

Comments

हाय स्टीवन, आपके इनपुट के लिए धन्यवाद। मैंने यहां एक और प्रश्न खोला है कि अल्टीमेटली इस प्रश्न के एक ही बिंदु पर पहुंच गई, और मैं आखिरकार इस समस्या के लिए एक क्लीनर समाधान प्रयास के साथ आया । क्या आप कृपया एक नज़र डालेंगे और अपने विचार साझा करेंगे? मुझे लगता है कि यह आपके सुझावों की दिशा में ऊपर जाता है।

— लेविदाद

ज़रूर बात लेविदाद, मेरी नज़र पड़ेगी!

— स्टीवन

मैंने सिर्फ 'वॉयस ऑफ अनरेसन' और 'एरिक ईड्ट' दोनों उत्तरों की जांच की। दोनों इस बात की तर्ज पर हैं कि मैं आपके द्वारा प्राप्त किए गए प्रश्न पर क्या टिप्पणी करूंगा, इसलिए मैं वास्तव में वहां मूल्य नहीं जोड़ सकता। और, आपके प्रश्न का उत्तर देने के लिए: जिस तरह से आप WebAppएआर हैं , 'क्लीनर सॉल्यूशन' में सेट किया गया है, आप वास्तव में एक एग्रीगेट के लिए एक अच्छे दृष्टिकोण के रूप में जो देखेंगे, उसकी तर्ज पर है। आशा है कि यह आपको लेविदाद की मदद करता है!

— स्टीवन